<attie>
is there a way to tell if any assignment is made to a signal elsewhere? I have a few signals that need to be driven/outputs, but my design sometimes uses them and sometimes doesn't depending on configuration parameters.
mumptai_ has quit [Quit: Verlassend]
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
m4ssi has quit [Remote host closed the connection]
<_whitenotifier-6>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fpjwC
<whitequark>
attie: you could write a pass in old migen
<whitequark>
but it seems like a code smell to me
<whitequark>
sb0: I am rather confused about the NO_CHANGE read port mode
<whitequark>
WRITE_FIRST and READ_FIRST map cleanly to logic. Yosys even has a TRANSPARENT attribute that switches between these two
<whitequark>
NO_CHANGE though is weird because it only considers *one* port
<whitequark>
e.g. if you have two write ports and n read ports, WRITE_FIRST and READ_FIRST always work properly
<whitequark>
but NO_CHANGE will only really work properly for the write port it's attached to (which is another weird quirk of migen, coupling of read and write ports) and for the others it silently degenerates into READ_FIRST
<whitequark>
AFAICT NO_CHANGE is not used in misoc or artiq, can we just deprecate it? I'll add a shim to nmigen.compat
<whitequark>
anyone who needs that semantics in nmigen can just add a single If() explicitly
rohitksingh has quit [Ping timeout: 250 seconds]
key2_ has quit [Ping timeout: 256 seconds]
lkcl has quit [Read error: Connection reset by peer]
<rjo>
whitequark: afaict in practice collisions between ports are typically only well-defined for one of the three styles. i forget which. and using an unsupported style may not even synthesize.
<whitequark>
rjo: that doesn't sound quite right according to my understanding of the synthesis toolchain and fpga memory implementations
lkcl has joined #m-labs
<whitequark>
for one, i think the way migen combines read and write ports is really strange in light of other things it does
<whitequark>
e.g.: if you don't ask for RE, it does not make an RE signal (as opposed to tying it to 1)
<whitequark>
but you cannot even ask for a purely write port, you *always* get a read port as well
<whitequark>
and the synthesizer is expected to eliminate it
<whitequark>
but this is mostly an interface oddity, because AFAIK synthesizers are okay at this job. so it doesn't pessimize designs.
<whitequark>
i want to talk about a different thing here.
<whitequark>
the memories in practice are a combinatorial product between two variables.
<whitequark>
variable B: port configuration. 1 read port, N read ports (degenerate case of 1 read port), 1 read port 1 write port, N read ports 1 write ports, N read ports M write ports
<whitequark>
the N/M case is not synthesizable.
<whitequark>
other than probably as DFF but no one wants that.
<whitequark>
N read port case is generally a degenerate variant of 1 read port case, where the write port is broadcast between multiple memories and each memory has a single read port
<whitequark>
for example, if you implement register file as distributed slice RAM and you want 2 read ports, what actually happens is you are using the xilinx (or ecp5 iirc) feature where a slice contains enough logic and the right routing for duplicating a memory
<whitequark>
internally, a 1 write port 2 read port slice RAM is just two memories on xilinx
<whitequark>
rjo: this is why i am saying that "collisions between ports being well defined for one of three styles" doesn't sound right to me
<whitequark>
when we are talking about FPGAs, there is no true multi-read-port or multi-write-port RAM in the first place
<whitequark>
so, there are no true collisions between ports
<whitequark>
so, it is not possible that one of those is not synthesizable
<whitequark>
one of READ_FIRST and WRITE_FIRST, I mean
<daveshah>
I'm pretty sure ECP5 and Xilinx BRAM has two genuine read/write ports
<daveshah>
Each port has three bitstream configurable modes. Normal, read before write and write through
<whitequark>
daveshah: i am intentionally not considering the cases which are synthesizable by direct techmapping
<daveshah>
In "normal" mode the read value is undefined during a collision
<whitequark>
because they are obviously synthesizable by definition
<daveshah>
Ah, that makes more sense
<daveshah>
Your understanding of distributed RAM read port duplication is definitely correct
<whitequark>
rjo: the only case where one of READ_FIRST or WRITE_FIRST is not synthesizable to BRAM is if your BRAM implementation has a single read port and a single write port that share address lines
<whitequark>
as far as I know there is no FPGA vendor dumb enough to actually implement that
<whitequark>
iCE40 has a dual port BRAM that has exactly one read and one write port, but they have separate address lines
<whitequark>
daveshah: ohhhh wow, I just noticed that iCE40 BRAM content is preserved during reconfiguration
<whitequark>
that's fascinating
<daveshah>
Yeah
<daveshah>
I think ECP5 would be the same too
<whitequark>
daveshah: how do you resolve conflicts in ice40 BRAM btw?
<whitequark>
by inverting clocks, right?
<daveshah>
I'm not sure what Yosys does. Don't think it's inverting clocks
<daveshah>
Inverting clocks screws up timing
<whitequark>
right, that's why i'm asking
<whitequark>
let me see
<daveshah>
I think the hardware has read before write semantics
<daveshah>
make_transp is set, so Yosys will add bypass logic if write through is needed
<whitequark>
I see now, thanks
cr1901_modern has quit [Ping timeout: 250 seconds]
<adamgreig>
whitequark: if I'm using the migen build system atm (for an ice40), is it worth looking at porting to nmigen now? would I have to diy the build beyond production of verilog?
<whitequark>
adamgreig: yes (because i could definitely use feedback from people using nmigen with real designs) and yes but I think you can reuse migen.build for that
<whitequark>
combining nmigen with migen.build is definitely going to be awkward
<adamgreig>
if I can get nmigen to spit out a .v it's a quick makefile or subprocess.run away from making a .bin, so I'm not too worried
<whitequark>
yeah that's easy, look at anything in examples/
<adamgreig>
I guess if anything I'm less sure about any other platform specific bits and pieces (tristate IO? BRAM?)
<whitequark>
BRAM is uh, well, i am adding Memory support to nmigen as we speak :)
<adamgreig>
heh
<whitequark>
tristate isn't currently done but it's like five lines of code overall, ping me once you need that and i'll just add it
<adamgreig>
sure, ok
<adamgreig>
I'll have a play then
<adamgreig>
looking forward to it
<adamgreig>
the context managers alone make it worth it