search

SpiNNakerManchester / spio

A library of FPGA designs and re-usable modules for I/O and internal connectivity in SpiNNaker systems.
BSD 3-Clause "New" or "Revised" License
6 stars 7 forks source link

Frame Assembler/Disassembler don't support rdy/vld at any time #6

Open mossblaser opened 10 years ago

mossblaser commented 10 years ago

Frame Disassembler features a couple of areas flagged as not supporting the valid signal. This problem causes frame errors whenever a clock correction sequence is sent and subsequently absorbed by the tx/rx_control modules.

Possibly fixed in: d7214a931156499463f1709a50750d43cc369b87

mossblaser commented 10 years ago

Frame Assembler and Frame TX both can't handle a rdy going low in the middle of a frame.

mossblaser commented 10 years ago

Proposed solution after discussion with @lplana: Add a pausable input to the tx_control block which indicates that in the next cycle, it is acceptable to remove the ready signal. At any other time, tx_control may not deassert the ready signal.

mossblaser commented 10 years ago

Associated TODOs:

Christian-B commented 4 years ago

So old assuming will not fix.

Please reopen if this is incorrect with an explanation as to why it still needs fixing.

Christian-B commented 4 years ago

@lplana We look forward to your fix of these bugs as unless you plan of fixing the bug there is no real reason for the issue to remain open.

Noone is claiming there is not a bug but without a plan to fix it why reopen the issues?

lplana commented 4 years ago

I stand corrected. My apologies.

pabogdan commented 4 years ago

@Christian-B I think at the very least we need to know what the issues are with each package that have yet to be resolved. If this mechanism isn't the issue being open, then what else can we use?

Christian-B commented 4 years ago

@pabogdan I am perfectly happy with all these issue being open if you or someone else is actually going to try to understand and maybe even fix the issues.

But to just leave issue open and untouched for 6 years appeared unprofessional.

pabogdan commented 4 years ago

We need to keep track of what does and doesn't work with the software in some manner that can be seen by everyone. If open issues are not the way to do this, then what else can we use?

mossblaser commented 4 years ago

If open issues are not the way to do this, then what else can we use?

I'd like to second @pabogdan and @lplana's sentiments here.

I sometimes refer to these repositories to refresh my memory of how I approached certain design issues in the past. Having these bug reports can be extremely valuable in warning me of cases where an example I'm looking at may not be as complete as I'd thought...

But to just leave issue open and untouched for 6 years appeared unprofessional.

I mean, sure, having 6-year-old bugs isn't ideal, but having 6-year-old undocumented bugs can only be worse?