| Summary: | dynamic pipeline chain signalling is timing-critical | ||
|---|---|---|---|
| Product: | Libre-SOC's first SoC | Reporter: | Luke Kenneth Casson Leighton <lkcl> |
| Component: | Source Code | Assignee: | Luke Kenneth Casson Leighton <lkcl> |
| Status: | RESOLVED INVALID | ||
| Severity: | enhancement | CC: | libre-soc-bugs |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| NLnet milestone: | --- | total budget (EUR) for completion of task and all subtasks: | 0 |
| budget (EUR) for this task, excluding subtasks' budget: | 0 | parent task for budget allocation: | |
| child tasks for budget allocation: | The table of payments (in EUR) for this task; TOML format: | ||
| Attachments: |
screenshot of gtkwave
screenshot of gtkwave (simpler case) |
||
change the value below from 3 to 2 to generate the succeeding case
class ExampleBufDelayedPipe(BufferedPipeline):
def __init__(self):
stage = ExampleStageDelayCls(valid_trigger=3)
BufferedPipeline.__init__(self, stage, stage_ctl=True,
buffermode=False)
Created attachment 6 [details]
screenshot of gtkwave (simpler case)
found a simpler case, a single pipeline, showing n_i_ready not
really working, which is very strange.
turns out not to be timing at all, was in fact the new buffermode=False. |
Created attachment 5 [details] screenshot of gtkwave signalling between two pipelines is somehow getting out of sync (where one does not) if the time-differential between d_ready and d_valid is only one clock, everything is fine. however if that is extended to 2 clock cycles, the output from pipe2 remains "valid" for one clock longer than it should. attached annotated drawing.