<sorear>
idle thought: current PCBs are 10-20 times larger than ICs were in 1970, and this could easily cross 1x in my lifetime
m_t has quit [Quit: Leaving]
<awygle>
how big were ICs in 1970? there are some darn small boards out there..
<awygle>
i was just thinking how much that Monster6502 board must have cost to fab
<awygle>
oh, i suppose you probably meant feature size. ignore me
thallia has joined ##openfpga
<sorear>
yeah, we're at a ~ 200 µm "process" right now
<smkz>
I have to design an FPGA-containing board disturbingly soon and it is rather terrifying :|
<awygle>
smkz: you'll be fine! boards are easy :)
* whitequark
stares at awygle
* awygle
whistles nonchalantly
<whitequark>
if I had a cookie every time I struggled with something on a PCB I'd have diabetes
<awygle>
i've been debugging the same software issue for the last 6 hours because there's ~200k lines of code, no debugger and the edit-compile-run cycle is about 20 minutes long
<smkz>
(not just FPGA-containing, there's also RF stuff that needs to be on the PCB ;-;)
<awygle>
right now i miss doing RF PCBs
<awygle>
i've been realizing more and more lately that regardless of "easy" and "hard" software stresses me out a lot more than hardware
thallia has quit [Ping timeout: 265 seconds]
thallia has joined ##openfpga
thallia has quit [Ping timeout: 276 seconds]
thallia has joined ##openfpga
pie___ has quit [Ping timeout: 240 seconds]
thallia has quit [Ping timeout: 248 seconds]
thallia has joined ##openfpga
unixb0y_ has joined ##openfpga
unixb0y_ has quit [Remote host closed the connection]
unixb0y_ has joined ##openfpga
thallia has quit [Ping timeout: 268 seconds]
unixb0y has quit [Ping timeout: 264 seconds]
thallia has joined ##openfpga
unixb0y_ has quit [Ping timeout: 264 seconds]
digshadow-w has quit [Ping timeout: 260 seconds]
thallia has quit [Ping timeout: 256 seconds]
thallia has joined ##openfpga
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 240 seconds]
unixb0y has joined ##openfpga
<qu1j0t3>
hehe
<qu1j0t3>
indeed, i do hardware to relax
unixb0y has quit [Ping timeout: 256 seconds]
thallia has quit [Ping timeout: 248 seconds]
digshadow has quit [Ping timeout: 268 seconds]
thallia has joined ##openfpga
unixb0y has joined ##openfpga
thallia has quit [Ping timeout: 240 seconds]
thallia has joined ##openfpga
digshadow has joined ##openfpga
unixb0y has quit [Ping timeout: 276 seconds]
RaivisR_ has joined ##openfpga
RaivisR has quit [Read error: Connection reset by peer]
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 240 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 248 seconds]
<rqou>
out of the loop: why are webdev people all upset about link tags or something?
GenTooMan has quit [Quit: Leaving]
unixb0y has joined ##openfpga
<whitequark>
rqou: you don't want to know
unixb0y has quit [Ping timeout: 260 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 248 seconds]
thallia has quit [Ping timeout: 248 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 256 seconds]
soylentyellow has quit [Ping timeout: 252 seconds]
thallia has joined ##openfpga
soylentyellow has joined ##openfpga
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 240 seconds]
<sorear>
I thought I was a webdev person and I hadn't heard
unixb0y has joined ##openfpga
soylentyellow has quit [Read error: Connection reset by peer]
unixb0y has quit [Ping timeout: 265 seconds]
unixb0y has joined ##openfpga
Bike has quit [Quit: Lost terminal]
unixb0y has quit [Ping timeout: 248 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 248 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 240 seconds]
<whitequark>
seriously. some things better stay not learned
unixb0y has joined ##openfpga
rohitksingh has joined ##openfpga
unixb0y has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 260 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 256 seconds]
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
rohitksingh has joined ##openfpga
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Quit: Leaving.]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 276 seconds]
rohitksingh1 has joined ##openfpga
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 255 seconds]
unixb0y has joined ##openfpga
eduardo__ has joined ##openfpga
unixb0y has quit [Ping timeout: 276 seconds]
eduardo_ has quit [Ping timeout: 260 seconds]
user10032 has joined ##openfpga
unixb0y has joined ##openfpga
thallia has quit [Ping timeout: 240 seconds]
unixb0y has quit [Ping timeout: 248 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 255 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 256 seconds]
m_t has joined ##openfpga
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 240 seconds]
gnufan has quit [Ping timeout: 240 seconds]
gnufan has joined ##openfpga
unixb0y has joined ##openfpga
uovo has joined ##openfpga
m_t_ has joined ##openfpga
pie___ has joined ##openfpga
laintoo_ has joined ##openfpga
m_t has quit [Remote host closed the connection]
laintoo has quit [Read error: Connection reset by peer]
awygle has quit [Quit: No Ping reply in 180 seconds.]
awygle has joined ##openfpga
calle__ has joined ##openfpga
oeuf has quit [Ping timeout: 256 seconds]
mumptai_ has quit [Ping timeout: 256 seconds]
gnufan has quit [Ping timeout: 256 seconds]
mwk_ has joined ##openfpga
stefanct__ has joined ##openfpga
Lord_Nightmare2 has joined ##openfpga
gnufan has joined ##openfpga
indy has quit [*.net *.split]
mwk has quit [*.net *.split]
Lord_Nightmare has quit [*.net *.split]
eric_j has quit [*.net *.split]
qu1j0t3 has quit [*.net *.split]
fouric has quit [*.net *.split]
stefanct has quit [*.net *.split]
Lord_Nightmare2 is now known as Lord_Nightmare
stefanct__ is now known as stefanct
stefanct has quit [Changing host]
stefanct has joined ##openfpga
pie___ has quit [Ping timeout: 256 seconds]
eric_j has joined ##openfpga
indy has joined ##openfpga
qu1j0t3 has joined ##openfpga
fouric has joined ##openfpga
gnufan has quit [Ping timeout: 255 seconds]
mwk_ is now known as mwk
pie___ has joined ##openfpga
gnufan has joined ##openfpga
thallia has joined ##openfpga
Bike has joined ##openfpga
grummel has quit [Ping timeout: 265 seconds]
grummel has joined ##openfpga
thallia has quit [Ping timeout: 260 seconds]
gnufan has quit [Ping timeout: 256 seconds]
rohitksingh1 has quit [Read error: Connection reset by peer]
thallia has joined ##openfpga
gnufan has joined ##openfpga
rohitksingh has joined ##openfpga
cr1901_modern has quit [Ping timeout: 248 seconds]
cr1901_modern has joined ##openfpga
gnufan has quit [Ping timeout: 265 seconds]
gnufan has joined ##openfpga
rohitksingh has quit [Ping timeout: 265 seconds]
RaivisR_ has quit [Quit: Leaving]
calle__ has quit [Remote host closed the connection]
gnufan has quit [Ping timeout: 256 seconds]
gnufan has joined ##openfpga
thallia has quit [Ping timeout: 240 seconds]
thallia has joined ##openfpga
thallia has quit [Ping timeout: 256 seconds]
thallia has joined ##openfpga
RaivisR has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
m_t_ has quit [Quit: Leaving]
soylentyellow has joined ##openfpga
<mithro>
morning!
<mithro>
tinyfpga: daveshah has started working on generating pb_type.xml files from verilog -- so building verilog models of the structures inside the ECP5 is probably the more productive way forward
thallia has quit [Ping timeout: 276 seconds]
thallia has joined ##openfpga
thallia has quit [Ping timeout: 240 seconds]
gnufan has quit [Ping timeout: 248 seconds]
gnufan has joined ##openfpga
rohitksingh has joined ##openfpga
gnufan1 has joined ##openfpga
gnufan has quit [Ping timeout: 248 seconds]
ZipCPU|Laptop has joined ##openfpga
gnufan1 has quit [Ping timeout: 240 seconds]
m_t has joined ##openfpga
gnufan has joined ##openfpga
thallia has joined ##openfpga
mumptai has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
GenTooMan has joined ##openfpga
unixb0y has quit []
thallia has quit [Ping timeout: 256 seconds]
thallia has joined ##openfpga
<tinyfpga>
mithro: awesome
<tinyfpga>
That’s what I’ll do then. I’ll document the structure of the various primitives and implement them in Verilog
<tinyfpga>
Along with the fuzzers to document the bitstream
<tinyfpga>
Been considering whether to use a placed and routed NCD or NCL file for most of the fuzzers...if I can do that then I get to skip a lot of extra complexity and deal with just the bitstream generation
<tinyfpga>
If I have ncl2ncd.exe it should be trivial. If I can use an ncl file directly in the bitmap generation phase it will also be trivial
<tinyfpga>
If I can’t do that then I’ll have to write write an NCD file generator
<tinyfpga>
Might not be too bad if it follows the NCL file structure
<daveshah>
`pb_type.xml`s are now being generated successfully, including XML includes, IOs, and direct interconnect. I still need to implement timing data, and mux interconnect if we want it. I am also wondering how the `equivalent` property of IO should be set, at the moment I'm not setting it. Should it be an attribute (setting `equivalent` to false unless specified?)
<mithro>
daveshah: I think just set to false for now
<daveshah>
OK, that sounds good
<mithro>
daveshah: I've yet to really figure out when is the correct place to not set that to true
<mithro>
daveshah: I think it is only the case when you have a full connected crossbar from the pins to something
<daveshah>
At the moment I haven't tested this actually with VPR yet, only verifying that the output is sensible. It does seem to handle the SLICEL sim.v at least correctly though - but some rearrangement of files will be needed it to work in VPR
<tinyfpga>
daveshah: any special requirements or limitations on the Verilog syntax to work with your tool?
<mithro>
daveshah: How does it compare to my hand written pb_type.xml files?
<daveshah>
The main requirement is that each pb_type must be a separate Verilog model and a separate Verilog file
<daveshah>
It looks OK, I see that one or two paths may actually have been missing in your hand written file. I've only checked to top level so far, need to look at the submodules still
<daveshah>
I also notice that the Xilinx architecture breaks autodetection of clocks because of the CLKINV module
<daveshah>
An attribute may be needed to force a clock on a given input
<mithro>
daveshah: BTW I'm okay with only routing muxes generated by mux_gen.py to be correctly identified as routing bels
<tinyfpga>
mithro, daveshah: is this what we should use to document the routing muxes as well?
<mithro>
tinyfpga: routing muxes == things "inside a tile" as opposed to switch boxes / fabric outside a tile...
<daveshah>
mithro: Should the "fundamental" pb_types like `vpr/ff/pb_type.xml` be elaborated from the Verilog? Or should we create a corresponding Verilog module and instantiate that to signify this case?
<mithro>
daveshah: Hrm?
<mithro>
daveshah: Actually, now that I think about it -- all the primitives which are mapped to vpr's ".class" types should probably be in the vpr directory
<daveshah>
mithro: Inside something like w5ff/pb_type.xml at the moment you include `vpr/ff/pb_type.xml`
<daveshah>
mithro: This won't be auto-generated at the moment
<mithro>
daveshah: So the things under vpr/XXX should map the the primitives that vpr has special understanding of
<daveshah>
mithro: How should the script know to find a primitive there though? Is it worth reintroducing some kind of path attribute?
<mithro>
daveshah: Does yosys loose the "the file the verilog model came from"?
<daveshah>
Actually, it doesn't. So we can have the pb_type.xml in the same folder as the Verilog
<mithro>
Yeah
<daveshah>
Each module has an attribute like "src": "tests/adder.v:1"
<mithro>
Yeap
gnufan has quit [Ping timeout: 264 seconds]
<mithro>
daveshah: I wonder if we should be using this tool to enforce style too? :-P
gnufan has joined ##openfpga
<mithro>
God I hate writing tests, even though it objectively makes me a lot more productive and I love *having* them
gnufan has quit [Ping timeout: 248 seconds]
<awygle>
i hate writing tests in C++. it's not so bad in some other languages
<mithro>
awygle: Plus it shows how terrible my code it :-P
<awygle>
mithro: well, there is that :P
gnufan has joined ##openfpga
soylentyellow has quit [Read error: Connection reset by peer]
soylentyellow has joined ##openfpga
<qu1j0t3>
so who wants to estimate my chances at getting a Terasic DE0 (Cyclone I) running. .... is anyone actually doing this now
<awygle>
running in what sense?
<daveshah>
OK, think I'm going to call it a day on VPR stuff... Just added provisional support for "<mode>" generation in pb_type, it's not an ideal implementation because it uses a (*MODE="x"*) attribute on cells, but there's not really a nicer way because parameters/conditional don't get preserved during elaboration. For actual simulation parameters/ifdefs could also be used otherwise you have a driver/driver conflict
<daveshah>
(which Yosys produces warnings about, but fortunately preserves, when generating JSON)
<daveshah>
Another remaining TODO is an override attribute for clocks, where automatic detection fails.
<rqou>
oh wtf why do i get ninja'd on everything i work on?
<awygle>
rqou: grad school
gnufan has quit [Ping timeout: 248 seconds]
futarisIRCcloud has joined ##openfpga
<qu1j0t3>
awygle: programmed, etc.
<mithro>
daveshah: We probably want the <mode> to be a generated case thingy?
gnufan has joined ##openfpga
<daveshah>
mithro: the problem is that yosys resolves parameters during elaboration and there's basically no way around that
<daveshah>
mithro: so about the only option you'd have if you did something like that would be to run yosys each time for each possible value
<rqou>
this is why earlier i pointed out that vhdl would work much better
<mithro>
daveshah: I'm happy with that
<rqou>
except we don't have that so we need a hack
<mithro>
daveshah: Actually, yosys has a mode were it reruns elaboration for a parameter change it seems?
<mithro>
daveshah: I'm also happy for us to depend on the parameter being named "mode"
<daveshah>
OK, that works
<rqou>
also wtf daveshah how do you have so much free time?
<daveshah>
rquo: basically because I pick modules at uni for minimum work and rarely bother with lectures. Then I alsolive with my parents so less housework etc
<daveshah>
mithro: would it be OK for everything inside the pb_type to depend on mode? Or would you prefer common stuff to be detected and pulled out
<mithro>
daveshah: Hrm?
<mithro>
daveshah: Any common stuff should be outside the mode section based on the verilog?
<daveshah>
mithro: Yes. It would seem "cleaner" if shared cells and interconnect wasn't in the mode section
<mithro>
daveshah: Well, you need an interconnect section per mode
<mithro>
(That maps the signals from the bits outside the mode, into the bits inside the mode)
<daveshah>
mithro: OK, probably easiest to keep all the interconnect inside the mode then
<daveshah>
mithro: That seems like a nice option, but does mean that we enter SystemVerilog territory
<mithro>
daveshah: I wonder if SystemVerilog supports enum for parameters?
<mithro>
daveshah: Define constants in the module of the form MODE_XXXX ?
gnufan has joined ##openfpga
<daveshah>
That's a good idea
<daveshah>
Other option is another attribute
<daveshah>
Like (* MODES = "LUT5 LUT6" *)
<daveshah>
And then LUT5 maps to 0 and LUT6 to 1
<daveshah>
Because I don't think constants make it to the json at present (but that would be an easy fix in Yosys)
<rqou>
er what
<rqou>
you can set attributes to strings or numbers and both are visible in the json
<mithro>
rqou: We know - the question is *possible* values for the parameter
<rqou>
i thought daveshah was proposing to have one string with all possible values?
<rqou>
or maybe i don't understand what "Because I don't think constants make it to the json at present" is referring to
<daveshah>
When I say don't make it to the json, I mean localparam constants
<rqou>
ah ok
<rqou>
i believe those do not
<mithro>
daveshah: Could we just make sure there is only one case statement for the parameter MODE and just look at what the case compares it too?
<daveshah>
I don't know if there's any nice way of doing that with yosys
<mithro>
daveshah: I wonder if proc_mux could be something that is useful? This pass converts the decision trees in processes (originating from if-else and case statements) to trees of multiplexer cells.
<daveshah>
The problem is that MODE is a parameter so it gets removed very early on.
<rqou>
the way i wanted to solve this problem that you're working on is to tag all variants with a (* alternative_to = "foobar" *)
<rqou>
and then have a foobar module tagged as a blackbox
<daveshah>
But the mux isn't removed
<mithro>
rqou: Want to add a "read_edif" to yosys? :-P
<rqou>
i already talked to clifford about that
<rqou>
edif sucks because there are many incompatible versions
<rqou>
why do you want it?
<mithro>
because it is not something I'm ever going to ninja you on :-P
<rqou>
but nobody seems to actually want it either
<mithro>
rqou: It would be useful for doing equivalence checks between yosys output and other tools
<mithro>
daveshah: I don't have a hugely strong preference -- we can always go back and refactor at another date
<mithro>
rqou's idea of tagging things as "alternative_to" could also work
<mithro>
bblr - going to find some lunch
gnufan has quit [Ping timeout: 256 seconds]
<daveshah>
mithro: yes, I think that's the option I'll go for at least for now
gnufan has joined ##openfpga
ZipCPU|Laptop has quit [Ping timeout: 240 seconds]