<fseidel>
we're getting dangerously close to VAX territory here
<whitequark>
i think variable length instructions for RISC are a superb idea
<whitequark>
i do that in my ISA
<whitequark>
it makes it waaaay nicer
<fseidel>
oh, I'm not saying variable length is a bad idea
<fseidel>
fixed width bit SPARC in the ass REAL hard (take a look at the way they handled vector extensions on VIIIfx, yuk)
<fseidel>
but 624 bits seems... extreme
<sorear>
i'm confused
<sorear>
there are two layers here: one which breaks a bit stream into "instructions", and one which decodes the individual instructions
<sorear>
why do you want to impose an arbitrary upper limit on length decoding?
<sorear>
length decoding needs to be as simple as possible for superscalar decode to work well
<fseidel>
I feel like imposing an upper limit makes it faster to decode though
<sorear>
(one of the things x86 *does* get wrong is that length decoding needs hundreds of cases, because only some instructions have modr/m bytes or immediates)
<sorear>
if a specific real chip doesn't implement any instructions longer than 64 bits, it only needs the 16b/32b/48b/64b cases
<futarisIRCcloud>
Looks like AntMicro were using it last year (with LiteX) ...
<sorear>
futarisIRCcloud: I don't follow the question re. Antmicro and Dolu's work on riscv32 linux support
<sorear>
there is currently a vexriscv fork with a software-managed TLB, and a hacked bbl+linux which works on it; daveshah did a demo
<sorear>
it would be possible to move all of the hacks to BBL so that Linux sees a standard S-mode environment, but AFAIK their plan is to modify vexriscv (at unspecified cost) to be more similar to Rocket, with a h/w page table walk
<keesj>
it that used in open source software (system verilog) ?
rohitksingh has joined ##openfpga
<daveshah>
Verilator supports them, and Yosys supports them for formal verification
<daveshah>
not sure about Icarus
<keesj>
Perhaps I am asking the wrong question. I want to write a test bench that (fully) tests my module
<SolraBizna>
iverilog does not have assume or assert, last I checked
<keesj>
how do I do that using open source tools?
<SolraBizna>
you can make a testbench module that uses `initial` blocks and delay statements to apply certain signals to the module you're testing
<SolraBizna>
then there are various non-synthesizable things (like `$display` and `$finish` and stuff for file I/O) you can use to get input to and output from such a testbench
<keesj>
I would like to validate some signals (e.g. assert like) but I also heard ZipCPU and others about formal validation. I don't really know where to start/how to start on this
<ZipCPU>
keesj: Have you looked at my tutorial at all?
<keesj>
(any comments on code are also welcome)
<keesj>
ZipCPU: I have read a few articles but no . did not follow any tutorial yet
* ZipCPU
reviews keesj's code
<ZipCPU>
Here's my thought: You want a property that following a reset, the design goes into a reset state for a minimum number of clocks before being ready (lest you get a reset, request, and response from prior to the reset)
<ZipCPU>
You'd also want a property (or set of properties) describing a sequence from request, through transmit, through waiting, through receive, through idle (or new request) again
<keesj>
so .. a reset state.. I will read the article (and find the tutorial :P ) thanks.
Richard_Simmons has quit [Read error: Connection reset by peer]
<elms>
keesj: There are many ways to shave a cat. I am far from an expert and also want to explore Formal methods more, but I'll mention cocotb and UVM in general *takes cover* Again not advocating any specific approach, but mentioning for context
<elms>
It's slightly more humane than the original idiom and I felt like it's more of a cat problem then a yak (ie it has claws and is fickle)
Bob_Dole has joined ##openfpga
<elms>
Does anyone have thoughts/pointers about determining internal delays for FPGA blocks? For example trying to reading and writing data at the same address to a RAM at almost the same time. RCLK and WCLK are not quite in sync. I recognize this should be avoided in real designs.
<azonenberg_work>
elms: you mean for cross clock stuff?
<azonenberg_work>
or the same clock domain?
<azonenberg_work>
elms: TMSC specifies write-to-read delays for their dual port sram IP, but it looks like xilinx's ram doesn't have any such spec
<azonenberg_work>
normally this isn't an issue because in a dual clock fifo, you have a 3-stage synchronizer between the write and read clock domains to keep track of the pointers
<azonenberg_work>
this adds a few clocks of latency so the data has more than stabilized by the time you need to read it
<azonenberg_work>
as a general rule i would wait at least one cycle of the faster clock after the write before reading
<azonenberg_work>
because that gives you the same effective setup time as if you had written then read back in the same domain
rohitksingh has quit [Ping timeout: 245 seconds]
Jybz has joined ##openfpga
<elms>
azonenberg_work: I'm looking at it for modeling it accurately for FPGAs (even for poor designs). I haven't been able to find any specs and hence why I was asking.
<azonenberg_work>
Yeah i dont see any specs
<azonenberg_work>
you could try measuring by writing in one clock domain and reading in another and sweeping pll phase until data gets corrupted
<azonenberg_work>
but i dont know how useful that will be, because that only gives you data for one particular die
<elms>
In general i think the lut+ff type blocks are well documented by vendors and all other blocks have a lot of missing details.
<azonenberg_work>
you'd need to test hundreds or thousands at a range of voltages and tempes to be confident you had a reliable spread for fast/slow PTV corners
<azonenberg_work>
Or you could test a few and extrapolate to get a conservative number
<elms>
azonenberg_work: I wonder if I can simulate a design and get some insight into any non published model they use
<azonenberg_work>
say double the worst case deviation you had seen or something
<azonenberg_work>
cant hurt to try but my gut says that isnt something their sim models will detect well
<sorear>
some, but not all, vendors are also silent on what happens if you do a simultaneous read and write from two ports sharing a clock
<azonenberg_work>
oh thats cool
<azonenberg_work>
UG473 page 20
<azonenberg_work>
xilinx specifies a 3000 ps collision interval
<azonenberg_work>
it just isnt in the datasheet
<azonenberg_work>
re simultaneous read and write with same OR different clocks, xilinx specifies clearly
<azonenberg_work>
i wish everyone did
<azonenberg_work>
for the most part though, dual port ram is normally 8T cells
<azonenberg_work>
So read-during-write will give nondeterministic read data and the write will execute normally
<azonenberg_work>
colliding writes will give nondeterministic data
<azonenberg_work>
and colliding reads are harmless
<sorear>
why wouldn't read-during-write just bypass the cells and have the write bit lines directly drive the read bit lines?
<sorear>
(I have a really weak understanding of sub-cycle event timing in SRAMs, which is probably the answer here)
<sorear>
(if you have any vaguely modern SRAM spec sheets to share with timing, I'd like to see)
<azonenberg_work>
The p1/p2 bitlines aare long and have parasitics
<azonenberg_work>
and sram write basically bus fights the bit cell and eventually wins
<azonenberg_work>
so midway through the state is unpredictable/metastable since you have 2 drivers on a shared bus
<whitequark>
oooh
<whitequark>
i have obtained mipi csi and d-phy specs
<sorear>
read-during-write adds load on the bit cell's side of the pass transistor, but I guess they budget for that
<azonenberg_work>
Yeah
<azonenberg_work>
the bigger issue is just that you have both the bitline and the inverter loop driving the other bitline
<azonenberg_work>
and the result isnt guaranteed to be consistent
<daveshah>
whitequark: which version?
<whitequark>
dphy 1.2, csi 2
<daveshah>
You mean CSI-2 or CSI-2 2.0 (yes it's stupid)
<daveshah>
I've only ever found a draft of CSI-2 1.0
<elms>
azonenberg_work: thanks fot the xilinx UG reference
<whitequark>
daveshah: what the fuck
Jybz has quit [Quit: Konversation terminated!]
<whitequark>
daveshah: CSI-2 1.01
<daveshah>
Nice, are you able to share?
<whitequark>
yea
<whitequark>
i'll upload them
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 276 seconds]
gnufan_home has joined ##openfpga
Laksen has quit [Quit: Leaving]
ZombieChicken has quit [Ping timeout: 256 seconds]
ZombieChicken has joined ##openfpga
carl0s has quit [Quit: Page closed]
Asu has quit [Remote host closed the connection]
Bob_Dole has joined ##openfpga
Richard_Simmons has quit [Ping timeout: 276 seconds]
Bike has joined ##openfpga
<mithro>
daveshah: Have you given a presentation / talk / anything else about the self-hosted nextpnr on the ECP5?
<azonenberg_work>
self hosted??
<azonenberg_work>
like, softcore risc-v with linux running on an ecp5?
<sorear>
yes
<sorear>
i don't think the full flow for the linux soc was run on the ecp5, but nextpnr-ecp5 did work in some case
<sorear>
the 45k, even (not the 85k)
<sorear>
this is riscv32 and still requires a lot of software handholding (all distro work has focused on 64-bit, only the 64-bit libc is upstream, and the linux-supporting vexriscv is still a bit immature and requires a patched linux)
genii has quit [Remote host closed the connection]
gnufan_home has quit [Quit: Leaving.]
azonenberg_work has quit [Ping timeout: 246 seconds]