danieljabailey has quit [Quit: ZNC 1.6.6+deb1ubuntu0.1 - http://znc.in]
danieljabailey has joined #yosys
pie___ has joined #yosys
pie__ has quit [Remote host closed the connection]
tecepe has joined #yosys
<tecepe>
hi, guys. yosys just came to my sight and i'm very impressed with your work. congratulations.
<tecepe>
do you know the FLAVIA project? (Free Logic Array via...)
<tecepe>
I was wondering if I wold be able to synthesize verilog code to that kind of architecture
<tecepe>
thank you very much for any suggestions =) i'm kind of lost on how to start
<ZipCPU>
FLAVIA?
* ZipCPU
googles FLAVIA
* ZipCPU
finds Offic coffee machines, mars drinks, and amazon page for a flavia creation 150 brewer ...
<tecepe>
ZipCPU: google for flavia free logic array
<tecepe>
=)
<tecepe>
it is a very simple fpga implementation
<tecepe>
it emulates an fpga in an fpga
<ZipCPU>
I had heard about something like this, but lost the link a long time ago
<ZipCPU>
It was sort of a "java byte code" for FPGAs sort of thing--something that could run on all FPGA's
<ZipCPU>
Last I heard, it wasn't very efficient at all
<ZipCPU>
Do you have any idea how efficient flavia is?
<tecepe>
It is not efficient
<ZipCPU>
Got it. Okay. Yosys is about as good as the device itself, although nextpnr isn't quite as good as the device is capable of
<tecepe>
Biggest problem is to provide access to io pins, where you need to multiplex everything to the cell
<tecepe>
to be honest, i'm not worried at all about the efficiency
<ZipCPU>
What are you concerned with then?
<tecepe>
i just wanted to put this path together, but i don't know how to start
<tecepe>
i imagine i have to "teach" yosys how to deal with that architecture, right?
<ZipCPU>
Hmm ... Okay, good question. I know more of how to use the tools than how to build with them
<ZipCPU>
Yes, you would need to implement your own back end
<ZipCPU>
Many backends have already been written
<ZipCPU>
Check out the technologymap (IIRC) directory of the yosys repo
<ZipCPU>
You should be able to find examples of what you need within there.
<tecepe>
ok, i think i was in the right path. i just was not able to find much info about this step
<ZipCPU>
Perhaps the best info would be from those who have done it
<tecepe>
I'll check that directory, thank you, this is already a good start =)
<ZipCPU>
rqou: Were you the one who had done the coolrunner2 implementation?
<tecepe>
Of course, if people that implemented those backend are around, it would be very helpful =)
<ZipCPU>
daveshah has been working on an ecp5 implementation. He's on European time, so you'll have to wait for his morning before chatting with hi
* ZipCPU
is sadly not one of them
<ZipCPU>
There's two problems though that you will need to work out: 1) The yosys back end, and 2) a place and route back end
<tecepe>
np, i'm glad you stepped in =)
<ZipCPU>
Most of the yosys team has been working on nextpnr, so you'll find backends for ice40 and ecp5 these days
* tecepe
is looking at that directory
<ZipCPU>
The yosys directory you need is the techlibs directory
<ZipCPU>
There's support within there for Altera/Intel, coolrunner2, easic (an ASIC flow), ecp5, gowin, greenpak4, ice40, intel, sf2, and xilinx
<ZipCPU>
I'm familiar with only some of those---mostly the ice40s
pie__ has joined #yosys
<tecepe>
that is great info
<tecepe>
thank you
pie___ has quit [Remote host closed the connection]
<ZipCPU>
;)
<tecepe>
nextpnr is a new place and route tool?
<q3k>
yes
<tecepe>
i have heard about arachne-pnr
<q3k>
arachne was developed as an ice40-specific pnr
<tecepe>
sorry, this world outside of vendor tools is pretty new for me
<q3k>
nextpnr is a new tool that's portable across multiple architectures
<q3k>
it has feature parity with arachne for ice40, and in progress support for ecp5
<q3k>
also a python-defined 'generic' architecture for experimentation
<q3k>
also it has a cute qt gui
<q3k>
and is timing driven (that's important :))
<tecepe>
wow, sounds fantastic
<tecepe>
you guys have been busy =)
<q3k>
mostly clifford and daveshah ^^
<tecepe>
how does this "python-defined generic" architecture work?
<q3k>
so every architecture backend currently defines what an architecture is to the core of nextpnr
<q3k>
by defining available Bels (basic elements, ie. physical blocks onto which Cells can be placed)
<q3k>
Pips (programmable inter..something point, ie. programmable switches)
<q3k>
and static Wires that connect Pips and Bels
<q3k>
for ice40 and ecp5 these are defined in C++ as a bunch of iterators and access functions (ie. letting the nextpnr core know what Bels exist, what Wires do these Bels connect to, etc.)
<q3k>
for the generic architecture, it starts with an empty definition of all of these in a bunch of hashmaps, and exposes a Python API to modify the architecture (add bels, pips, wires)
<q3k>
so you would write Python code that populates all the architecture elements in the architecture, and then tell nextpnr to get to work
rohitksingh_work has quit [Ping timeout: 250 seconds]
rohitksingh_work has joined #yosys
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #yosys
fsasm has joined #yosys
seldridge has joined #yosys
fsasm has quit [Ping timeout: 250 seconds]
pie___ has joined #yosys
pie__ has quit [Remote host closed the connection]
rohitksingh_work has quit [Read error: Connection reset by peer]
seldridge has quit [Ping timeout: 250 seconds]
kuldeep has quit [Read error: Connection reset by peer]
cr1901_modern has quit [Ping timeout: 240 seconds]
rohitksingh has joined #yosys
tecepe1 has joined #yosys
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined #yosys
cr1901_modern has joined #yosys
emeb_mac has joined #yosys
indy has quit [Read error: Connection reset by peer]
seldridge has joined #yosys
FL4SHK has joined #yosys
<ZipCPU>
Hey, this is cool: I just adjusted how I was going about the formal verification of the ZipCPU. By checking the current state instead of transitions between states, I can now verify the CPU in less than 15 steps--vs 18 (or more) before
indy has joined #yosys
<ZipCPU>
I'm current working with the ZipCPU+data cache, and I can verify the two together in only 10 steps
<ZipCPU>
That's a full proof: BMC+Induction too
seldridge has quit [Ping timeout: 240 seconds]
emeb_mac has quit [Quit: Leaving.]
seldridge has joined #yosys
lutsabound has joined #yosys
maikmerten has joined #yosys
m4ssi has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 250 seconds]
dys has joined #yosys
develonepi3 has joined #yosys
<jer>
ZipCPU, cool
lutsabound has quit [Quit: Connection closed for inactivity]
tecepe1 has quit [Ping timeout: 245 seconds]
lutsabound has joined #yosys
FL4SHK has quit [Quit: leaving]
ashfixit has quit [Quit: BitchX-1.2.1 -- just do it.]
maikmerten has quit [Remote host closed the connection]
emeb_mac has joined #yosys
tecepe has quit [Ping timeout: 244 seconds]
seldridge has quit [Ping timeout: 240 seconds]
lutsabound has quit [Quit: Connection closed for inactivity]