<mithro>
tinyfpga: hey - you around? I have a project proposal for you :-P
<mithro>
tinyfpga: oh, and would you be interested in mentoring a student as part of Google Summer of Code to hack on SymbiFlow?
gnufan has quit [Ping timeout: 256 seconds]
<awygle>
mithro: are you at all worried about the legal status of SymbiFlow?
gnufan has joined ##openfpga
<mithro>
awygle: We have good advice that our approach is perfectly protected
<awygle>
mithro: that's good to hear. does that advice rely on specifics of (e.g.) the Vivado license?
<awygle>
by which I mean is the ecp5 work covered, basically
unixb0y has quit [Remote host closed the connection]
unixb0y has joined ##openfpga
gnufan has quit [Ping timeout: 240 seconds]
unixb0y has quit [Ping timeout: 260 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Remote host closed the connection]
unixb0y has joined ##openfpga
gnufan has joined ##openfpga
thallia has quit [Ping timeout: 252 seconds]
thallia has joined ##openfpga
unixb0y has quit [Ping timeout: 264 seconds]
unixb0y has joined ##openfpga
gnufan has quit [Ping timeout: 240 seconds]
unixb0y has quit [Ping timeout: 248 seconds]
unixb0y has joined ##openfpga
gnufan has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<mithro>
awygle: I assume if tinyfpga follows the same approach we have
unixb0y has quit [Ping timeout: 268 seconds]
gnufan has quit [Ping timeout: 260 seconds]
* sorear
idle wonders how much worse it would be to deal with something like microsemi's where the bitstreams are encrypted
<awygle>
ecp5 supports encryption of the bitstream
<sorear>
microsemi's tools do not support generating non-encrypted bitstreams. the documentation is silent on whether the chip would accept one if you made one
<sorear>
(the polarfire docs are the ones I've been reading)
<awygle>
huh interesting
gnufan has joined ##openfpga
* awygle
pictures his work todo list, with "encrypt ecp5 bitstream" written towards the bottom
<awygle>
sorear: my understanding is that it would only be worse if you broke the encryption. Which depending on how it's implemented you might or might not need to do in order to generate a valid bitstream.
<sorear>
if the tools can't export an unencrypted bitstream, then you'd need to determine the encryption algorithm before you could write fuzzers
<awygle>
Right, but that's not the same as breaking it
<awygle>
It may be "use AES256 with whatever key you like and burn same key into on board storage", in which case I believe that as long as you're not stealing a key you're no worse off
<awygle>
Not a lawyer etcetc
<awygle>
If there's a key burned into the chip, then yes, you'd need to get it and that would probably be illegal.
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 256 seconds]
mumptai_ has joined ##openfpga
pie_ has quit [Ping timeout: 248 seconds]
mumptai has quit [Ping timeout: 256 seconds]
gnufan has quit [Ping timeout: 264 seconds]
GenTooMan has quit [Quit: Leaving]
gnufan has joined ##openfpga
futarisIRCcloud has joined ##openfpga
gnufan has quit [Ping timeout: 260 seconds]
<tinyfpga>
yeah, I’m not cracking any encryption and I have no interest in that
<tinyfpga>
the bitstream format for FPGAs is no different than the ISA of a CPU architecture
<tinyfpga>
if anyone is afraid of people reverse engineering their IP by pulling their FPGA design off a SPI flash, then they should encrypt their bitstream
<tinyfpga>
both Lattice and Xilinx have these options
<tinyfpga>
mithro: I’m around here and there, let me know what it is...I might be able to help if it aligns closely with something I’m already doing
rohitksingh has joined ##openfpga
<awygle>
my concern is mainly related to breaking the license/user agreement/terms of service. my (nonlawyer) research indicates that that can get you in trouble.
gnufan has joined ##openfpga
unixb0y has joined ##openfpga
<mithro>
tinyfpga: Have you seen my Tomu board? https://tomu.im/
unixb0y has quit [Ping timeout: 264 seconds]
gnufan has quit [Ping timeout: 240 seconds]
<tinyfpga>
mithro: yup! Looks pretty cool
unixb0y has joined ##openfpga
<mithro>
xobs: Wanted to create a similar board based on the ice40 running a picorv32
<mithro>
tinyfpga: With your USB stack and the new ice40 support it seems like it would be pretty easy
<tinyfpga>
mithro: sounds pretty interesting
<tinyfpga>
mithro: I once made a small microcontroller-based “redneckifier”
<tinyfpga>
mithro: it converted keywords typed on a USB keyboard into “redneck” versions
<mithro>
tinyfpga: Could even probably do some crypto acceleration
<tinyfpga>
mithro: it fit in between the usb keyboard and usb host...it was pretty hilarious to prank coworkers with it...
<mithro>
tinyfpga: Ha
<tinyfpga>
Yes, an FPGA tomu would be especially neat
rohitksingh has quit [Read error: Connection reset by peer]
<mithro>
tinyfpga: Just need to decode the MachX02/3 bitstream too :-P
dingbat has joined ##openfpga
<mithro>
tinyfpga: Anyway - something to think about
thallia has quit [Ping timeout: 256 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 256 seconds]
thallia has joined ##openfpga
<tinyfpga>
mithro: I’ll keep it on the back of my mind
<tinyfpga>
mithro: by the way, it looks like I can create fuzzers that use the NCL format...so I can place any primitive anywhere without worry of things being optimized away
<tinyfpga>
mithro: I can also set any and all muxes in the switch boxes
gnufan has quit [Ping timeout: 260 seconds]
<awygle>
tinyfpga: i have an interest in the ecp5 and i own two dev boards using it. let me know if i can help, maybe we can divide up the work to some extent.
unixb0y has joined ##openfpga
gnufan has joined ##openfpga
Bike has quit [Quit: Lost terminal]
unixb0y has quit [Ping timeout: 268 seconds]
noobineer has joined ##openfpga
digshadow has quit [Ping timeout: 248 seconds]
thallia has quit [Ping timeout: 252 seconds]
digshadow has joined ##openfpga
thallia has joined ##openfpga
thallia has quit [Ping timeout: 260 seconds]
unixb0y has joined ##openfpga
thallia has joined ##openfpga
unixb0y has quit [Ping timeout: 264 seconds]
<rqou>
tinyfpga, mithro: the NVCM is OTP
<rqou>
we also don't know how to program it
<rqou>
this was _just_ discussed btw, so you might want to check backlog
<whitequark>
rqou: huh??
<whitequark>
page 23 of TN1248
<rqou>
wait what
<rqou>
i though that was the slave SPI timing diagram
<whitequark>
it ways "waveforms for NVCM programming"
<rqou>
in that case i guess we just need to implement it because iceprog doesn't currently support it
thallia has quit [Ping timeout: 248 seconds]
noobineer has quit [Ping timeout: 256 seconds]
thallia has joined ##openfpga
<mithro>
Lattice calls its NVCM update process Multi Time Programmability (MTP). Currently MTP technology can be used to store two different configurations of the FPGA.
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 260 seconds]
soylentyellow has quit [Ping timeout: 264 seconds]
<daveshah>
I think there's some confusion here - remember the ice40 is not a lattice part at heart.
<daveshah>
The machxo2 does have reprogrammable nvcm, but only a couple of times iirc
<daveshah>
The ice40 nvcm is only programmable once.
<sorear>
how many zeros does the "couple of times" have?
<daveshah>
None... I think it allows 2 or 3 times. It's just OTP, but duplicated as many times as it can be reprogrammed
<azonenberg>
mithro: when i hear MTP i think of fiber optics
<azonenberg>
lol
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 240 seconds]
mumptai_ has quit [Quit: Verlassend]
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 276 seconds]
RaivisR_ has joined ##openfpga
RaivisR has quit [Read error: Connection reset by peer]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 240 seconds]
m_t has joined ##openfpga
<rqou>
halp, hugin is the hard
unixb0y has joined ##openfpga
user10032 has joined ##openfpga
unixb0y has quit [Ping timeout: 276 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Remote host closed the connection]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 256 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 240 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 240 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 260 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 264 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 276 seconds]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 252 seconds]
pie_ has joined ##openfpga
unixb0y has joined ##openfpga
unixb0y has quit [Remote host closed the connection]
unixb0y has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 256 seconds]
rohitksingh has joined ##openfpga
Bike has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
<mithro>
daveshah: did my comments make sense?
rohitksingh has quit [Client Quit]
<daveshah>
mithro: Yes, thanks, I think I've done all the relevant refactoring now, and also switched modes to use rquo's suggestion
<daveshah>
mithro: I still need to make a better example case than the adder/LUT thing I made as a quick test. But it should be a bit clearer now at least
<mithro>
daveshah: just getting up now, will have another look soon
<daveshah>
mithro: No worries. Let me know if you have any more questions/comments.
<cr1901_modern>
daveshah: Hopefully I'll have time to try to figure out the source of my arachne woes today or tomorrow
<daveshah>
cr1901_modern: Yes, it would be useful to know what's going on. The latest arachne-pnr master will reject binary chipdbs of the wrong version, eliminating that possbility
<cr1901_modern>
daveshah: That does not help me unfortunately if arachne is attempting to read a chipdb without that version information from the wrong path (which I suspect is happening)
<cr1901_modern>
But noted :)
<daveshah>
cr1901_modern: It should still detect that, and will print the "bad version" message, but obviously won't tell you what the actual version of the bad chipdb is
<cr1901_modern>
Ahh okay then
<mithro>
daveshah: the next step would be to move everything in the arch-defs repo to use your tool
pie_ has quit [Ping timeout: 240 seconds]
<daveshah>
mithro: Yes, a bit of Verilog will need changes as a result, but that sounds like a good way forward. The only thing I need to add before it should describe most, if not all, stuff is combinational delay specifications.
<daveshah>
mithro: As there's no timing specification support in Yosys at all, are you OK continuing to use attributes for timing, however impure that feels?
<mithro>
Feel right to me
<mithro>
It would be good to start writing unit tests for the verilog as well :-P
<daveshah>
mithro: Yes. Part of me wants to look at formal verification options too, but simulation testbenches are probably the best place to start. Doing formal equivalence checks against the vendor's models for the basic cells could also be an interesting thought at some point.
<mithro>
Yeah
<mithro>
Although you should note that the verilog models inside the arch defs repo should match actually the hardware
<mithro>
We then provide what I'm going to call "macros" which map from the vendor's libraries to our arch defs
<mithro>
daveshah: I'm all for putting formal asserts in our models
<daveshah>
mithro: Yeah, although writing formal properties at such a low level may not be that helpful as often your properties will basically be a direct duplicate of the logic and not really test anything
<mithro>
But I have no idea how :-)
<mithro>
I think asserts around timing are likely to be more useful - IE X always changes after Y
<mithro>
Never done any formal stuff
<daveshah>
mithro: Yes, this is true, also things like guaranteeing signals are stable under certain conditions
<daveshah>
mithro: I've only really started a few weeks ago...
<daveshah>
mithro: Testing ZipCPU's formal verification course, which I can recommend if there is ever an opportunity for you to do it :)
<mithro>
Can we formally assert things like setup / hold timings?
<cr1901_modern>
Prob not w/ yosys
<daveshah>
mithro: No, not really, but you can assert relative timing/stability using $rose, $fell, $stable, $past, etc
<daveshah>
mithro: It is even possible to verify multi-clock-domain stuff using Yosys
<mithro>
Isn't setup / hold time all relative to the clock edges?
<cr1901_modern>
The clocks still have to be synchronous to $global_clock.
<daveshah>
mithro: Yes, cr1901_modern is correct. You can't have really edges at arbitrary positions
<daveshah>
But you can have things like clocks with an arbitrary relationship between them
<mithro>
I don't really know what that means :-)
<cr1901_modern>
I haven't done formal verification that much, even tho I got started around the same time as ZipCPU. But even with a single clock, I find I need a statement like this: https://github.com/cr1901/spi_tb/blob/mvce/spi_tb.v#L78-L81
<mithro>
cr1901_modern: so, how's your formal SPI + migen-formal going?
<cr1901_modern>
mithro: There are other issues I've since forgotten since I decided this wasn't worth the pain
<mithro>
cr1901_modern: ahh you need the ability to override the verilog output printing?
<mithro>
I feel like the output side of Migen should be more pluggable
<mithro>
IE if someone wanted to output VHDL
<mithro>
cr1901_modern: have you ever used myhdl?
<cr1901_modern>
No
<cr1901_modern>
I am pretty resistant to learning new languages, tbh
<mithro>
Put it on your "I should check this out when I have free time" list :-)
<mithro>
Btw we should merge you SPI changes...
<cr1901_modern>
Prob, but I'm in no rush :P
<cr1901_modern>
And yes, migen needs to understand new types of nodes. It needs to be able to add signals that are only used as part of asserts and not the design proper.
<cr1901_modern>
It needs to understand concurrent/immediate assertions and how to output them in the Verilog correctly. I may also have to give up auto-detecting what type of assertion the user meant.
<mithro>
I'd really like to get atleast spimode bitbanging of sdcard support merged ASAP...
<daveshah>
mithro: I have added the combinational delay specification support to the scripts, and now removed WIP from the PR given we have a reasonable framework to start doing stuff with. I don't know whether there's anything else that needs to be done before merging though?
<mithro>
I'm just walking to the train station ATM
<mithro>
When I get there, will take a look
<cr1901_modern>
mithro: privmsg
<mithro>
daveshah: I think Clifford had a ice40 bitstream to Verilog converter
<daveshah>
mithro: Yes, he does, icebox_vlog
<mithro>
cr1901_modern: don't see anything?
<cr1901_modern>
Just sent it
<daveshah>
mithro: It converts it to "plain" Verilog (`assign` with expressions for logic and `always` for FFs) rather than cells for the most part though
GenTooMan has joined ##openfpga
<mithro>
Brb - raining
<mithro>
Back online when under cover at train station
<mithro>
back now
<mithro>
daveshah: cells?
<mithro>
daveshah: I'm terrible at verilog :-P
<mithro>
daveshah: You going to start the conversion process or head to bed? :-P
<daveshah>
mithro: Will probably start looking at conversion this evening. It's only 4:40pm here in the UK, plenty of hacking left :)
<daveshah>
mithro: what I meant by not generating cells is that it won't instantiate something like `SB_LUT` or `SB_DFF`, instead it will generate the equivalent verilog directly
<daveshah>
mithro: so it's output is quite different from the style of Verilog we're writing
<daveshah>
*its output
<daveshah>
mithro: Should I base the conversion off your Artix-7 branch, or off the current master?
<mithro>
daveshah: My artix-7 branch
<mithro>
daveshah: Just reviewing the code now
<daveshah>
mithro: Brilliant. Also, if there are any conflicts, I presume the `pb_type` is more likely to be correct and I should update the Verilog?
<daveshah>
mithro: Also looks like the first step will be just modifying the make infrastructure to support generating the XML files automagically
<mithro>
daveshah: Yes correct
<mithro>
The pb_type's are much more likely to be correct then the verilog
<mithro>
daveshah: Review comments added
<daveshah>
mithro: Thanks
<mithro>
daveshah: I think I just realized there is a bit of confusion here
<mithro>
daveshah: really only the things under the vpr directory should end up with the port_class properties (except maybe memories?)
<daveshah>
mithro: We can still generate those primitives from a Verilog module though I think? A verilog model would also be useful for those so we can instantiate them further up the hierarchy.
<daveshah>
mithro: Unless you mean you want to auto elaborate those primitives rather than instantiating them?
<mithro>
daveshah: Yes -- we should be generating the stuff in vpr directory from verilog too
<mithro>
daveshah: but I think there are two modes? One were we generate the "BELs" in the vpr directory and one were we generate pb_types which references the BELs in the vpr?
<daveshah>
mithro: I understand the first one. For the second, what exactly do you mean by reference?
<mithro>
daveshah: The verilog code should `include the verilog file from the vpr directory and instantiate it -- then in the pb_type.xml you want it to do an <xi:include> the correct pb_type.xml from the vpr directory?
<mithro>
daveshah: I think ?
<daveshah>
mithro: Yes, that's exactly what I had in mind and how things are structured at the moment. I think the main changes needed are just to the way types/classes are handled, as you mentioned in the review.
<mithro>
daveshah: They should be blackbox modules when converting to pb_types but we actually *do* want verilog models of how they work
<daveshah>
mithro: Yes, that's a good idea. For `model.xml` generation, I think it's best to set SIM and then flatten the hierarchy (as we do at present), so subcells are ignored but combinational paths etc can be automatically inferred.
<mithro>
daveshah: I wonder if we should be using some type of techmap type thing to figure out the vpr primitives to use?
<mithro>
daveshah: We only get model.xml files for blackbox objects
<mithro>
daveshah: and bels
<mithro>
well
<mithro>
blackboxs are "bels"
<mithro>
I keep making that same mistake of thinking they are different
<daveshah>
mithro: I'm not sure about the techmap. Part of me thinks that just requiring manual instantiation is going to be more reliable.
<mithro>
daveshah: Yeah - might be a way to check the manual instantiation is valid?
<daveshah>
mithro: It's worth a thought, although hopefully that will be handled by the testbenchs and manual instantiation will also instantiate a simulation model of the relevant cell
<mithro>
daveshah: BTW Don't assume I know what I'm talking about -- learning this all fresh too :-)
<daveshah>
I think it might need attributes of any kind to be added to the parser first.
pie_ has joined ##openfpga
<mithro>
Maybe
<mithro>
Arrived in San Francisco, will be back in 30ish minutes
<unixb0y>
what mobile IRC clients do you guys use?
<daveshah>
unixb0y: I use IRCCloud
<daveshah>
recommended by mithro
<unixb0y>
okay, thanks! I'll check it out now :) It's actually free on iOS
<unixb0y>
I don't understand why I should register with my Email?
<daveshah>
It's a cloud service rather than just a client (depends if you want that or not.)
m_t has quit [Quit: Leaving]
<unixb0y>
hmm I see. Don't need no cloud for everything.... ;)
unixb0y has left ##openfpga [##openfpga]
unixb0y has joined ##openfpga
unixb0y has quit [Ping timeout: 276 seconds]
<daveshah>
mithro: I notice the current naming scheme of several `pb_type`s is not valid verilog (such as `BEL_BB-CARRY4`) because of the hypen. Shall we change the hypen to an underscore, or allow the Verilog module name and pb_type name to differ?
<mithro>
daveshah: The front part should be generated from the other properties
<daveshah>
mithro: OK, makes sense
<mithro>
daveshah: Yeah - see the readme
<tinyfpga>
unixb0y: I use mutter on iOS and znc to handle notifications and stay connected
unixb0y has joined ##openfpga
<mithro>
daveshah: Poke me when you want to review it again
<daveshah>
mithro: I've just done the naming changes now. I think that will be it for today, I've got some other stuff I should probably be getting on with... Feel free to look at what I've done, I think I've dealt with at least a few of the points and also left comments on a few others.
unixb0y has quit [Ping timeout: 240 seconds]
unixb0y has joined ##openfpga
m_t has joined ##openfpga
m_t has quit [Max SendQ exceeded]
m_t has joined ##openfpga
mumptai has joined ##openfpga
eduardo_ has quit [Quit: Ex-Chat]
m_t has quit [Quit: Leaving]
<rqou>
so i need to start a brand-new more-or-less-greenfield microcontroller project
<rqou>
should i use japaric's work?
<rqou>
my major concerns with it are: * what if i do need to interop with C code still
<rqou>
* i need to collaborate with a classmate, will i have an uphill battle if i pick rust?
<rqou>
* is it stable enough to trust?
<rqou>
whitequark: thoughts?
<awygle>
rqou: * C FFI should be doable * yes * probably if you stick to Cortex-M
<rqou>
my concern with c is if the code i steal needs a bunch of libc crap
<rqou>
because afaict i won't have any c runtime at all
<rqou>
i might actually need things like "sin" and "cos"
<rqou>
(yes, those can be implemented in Rust too
<awygle>
it's been a while since i was active in this space but i thought japaric showed linking to newlib at least once
<rqou>
this is why i have a stalled project to take musl libc and rip out only the "pure-function-ish" bits
<cr1901_modern>
I imagine there's a no_std crate for trascendental functions, even in software without FPU. No I haven't checked, nor do I intend to :P.