 So, it's my very great pleasure to introduce to you Clifford, who's going to talk about a very complex topic I know very little about, but that's probably going to change now. So please give a warm round of applause for a free and open source very-locked 2-bit stream flow for ISE 40 FPGAs. Thank you. So I'm talking about a free and open source very-locked 2-bit stream flows for ISE 40 FPGAs. And in particular that means I'm going to talk about three projects, because these three projects together form this free and open source very-locked 2-bit stream flow for this kind of FPGAs. The projects I'm going to talk about are Project ISTORM. And Project ISTORM is an effort to reverse engineer and document the bit stream format for ISE 40 FPGAs. And in particular, right now, we support the HX1K and HX8K FPGAs. In theory, we should only also support the LP1K and LP8K, if there is such a one, I don't know, FPGAs, because they just have different timings, but the bit stream format is absolutely identical. So from the ISTORM project, we get documentation for the bit streams, documentation as well as in human readable form, as well as in machine readable form, so we can write other tools that do then useful things with this kind of devices. And also from Project ISTORM, we have a couple of tools that we can use to read bit stream files for those FPGAs and convert those bit stream files into different formats and vice versa. The second project I'm going to talk about is Arachne PNR. And Arachne PNR is a place and route tool for the ISE 40 FPGAs. And it's based on the ISTORM documentation. So I wrote the ISTORM documentation, and then I was lucky enough to find someone caught and see this name to write this Arachne PNR place and route tool based on the documentation I wrote. The third project I'm going to talk about is YOSUS. And YOSUS actually is my kind of main project that I'm working on now for a little bit over three years. And YOSUS is a huge project, but simply said, it's a very log synthesis suite. So when you have hardware designs that are written in very log, you can use YOSUS to synthesize those designs to net lists for a variety of different architectures. And one of those architectures is the ISE 40 FPGA architecture. But I also have support for other FPGA series there, I have support for ASIC synthesis, and they also support various formal verification flows in YOSUS. And I'm going to talk about this a little bit, not very much, just a little bit. And last but not least, I'm going to talk about the ICO board. The ICO board is a development board featuring the ISE 40 FPGAs. And I'm also showing you a little demo, and that's this contraption here. We are going to use this at the end of the talk. So this is the flow, the big overview for the flow. You see, you start with very log sources and the synthesis script. Usually the synthesis script just reads the very log files and then executes a few macro commands that do everything that is necessary to synthesize for the specified target. And of course, we are looking at the ISE 40 FPGA here in particular. The output of YOSUS in this case is a bliff file. Bliff is a very easy, very simple, netlist format. And it's one of many formats that YOSUS supports as backends. We've made some extensions to the bliff file format to enable the use of additional attributes on cells and parameters, which is quite useful when you do, for example, FPGA synthesis and would like to have the load configuration as part of a cell instantiation as a kind of parameter. Then we take this netlist and the bliff file and we pass it on to Arachni PNR, the place and route to Wittenberg-Hotensied. And we also give Arachni PNR a few additional files. Namely, we give it a physical constraints file that specifies where each pin should go on the, where each input or output of the design should go on the device, to which pin it should map. Optionally, you can also specify a place and route script that tells Arachni PNR what strategy it should follow and what of its internal passes it should execute in what order. The output of that is what I call an ice storm text file. This is already a very, very low-level file format. We will see a short example of that where you can see for each individual tile just the ASCII block of zeros and ones and then, you know, okay, in line eight and column 13 is bit that has this or that function. And lastly, we pass this ice storm text file to Icepack. And Icepack is a very simple tool that can convert this easy to read text file into the binary representation that must be passed to the FPGA in order to use this design. Yeah, so let's look at the first of those four projects, the first part of my talk, Project Ice Storm. First, I think I should give you a little overview over the Ice40 FPGA series because the Ice40 FPGAs are not very widely used. I mean, a lot of people use Xilinx devices or Kera devices, but let this Ice40 kind of niche. So it's a family of small FPGAs. The largest one has a little bit under 8,000 Lutz. And the Lutz are small four-input Lutz. The FPGA itself is, of course, a kind of grid of tiles and the different kind of tiles. There are logic tiles, and those logic tiles have eight lookup tables, and for each of those lookup tables, an optional flip-flop and a carry chain logic that you can use optionally. There are also RAM tiles for block memory. They always come in pairs. There's always a RAM bottom tile and a RAM top tile, and the bottom tile and the top tile together, they form a 4-kilobyte S-RAM. And of course, there are IO tiles on the edges of the grids that connect to the programmable IO pins, but also provide the infrastructure necessary to connect the FPGA logic with other resources on the chip, like PLLs and the overnets. A nice thing about I-Sport the FPGAs is that they come in quite reasonable packages. So when you would like to make your own boards, it can be quite a hassle to work with ball grids, arrays, and stuff like that. But the I-Sport the FPGAs come in packages like 144-pin QQFP that you can even solder by hand if you have to. And although there are very cheap development boards available from Lattice directly for this kind of FPGAs, the Lattice I-Stick costs less than $25, so it's really affordable for someone who just would like to experiment with it and have a quick go with it. Also, if you would like to do some low-level stuff and are afraid of maybe breaking your dev board by fiddling with the configuration bits manually, then it's quite nice to have a dev board in this price range where nothing is... Yeah, where you can simply replace it. So in summary, the FPGA looks a little bit like that. We have this grid of PLBs, programming logic blocks. These are the logic tiles. We have some memory tiles that span two rows, and we have the IO tiles on the edges. And then in the middle of that slide, we have a more detailed look into one of these logic tiles where we see we have these eight flip-flops, eight carry chain elements, and eight lookup tables. This is also blown up here, so we can see it in more detail. However, this is still just... It's still missing stuff. For example, there is a connection that goes directly from one loot output to the second loot input of the next lookup table in this chain bypassing the flip-flop. Yeah, and the bottom right you see, this is the iStick dev board that you can buy from that for under $25. I think it costs $25 from lettuce, but on Mauser it's under $25. Good, so with Project iStorm, we had a detailed look at this FPGA, and we documented the bitstream format, and we wrote these low-level tools that can be used to work with bitstreams. And we also defined a very simple text file that can be used to just specify each and every individual bit in the configuration. Right on this slide you see a little excerpt of what this text file looked like. So you have here logic tile 99, and these are, of course, the coordinates, and then you just have this block of ones and zeros. And when you look up the documentation online that we provided, then you can decipher that and say, okay, this bit is set because it has this function, and this kind of makes sense for what this configuration does. So with the iStorm tools, we can convert between the text files and the binary files, and we can also do a lot of other interesting stuff. For example, we can take one of those text files and convert it back into a behavioral virolog model. And actually when I released this feature the first time, I got quite some hate mail from people who thought I wanted to steal their IP or something. You can also create timing netlists from these bitstreams directly. However, this is under construction. It's almost done, but not quite yet. The reason why we're doing things like that always on this low-level bitstream format is because we can create these files from our own flow, but we can also create it for the bitstream files generated by a lettuces flow. So it's very easy to verify if our interpretation of the bitstream is correct, which is just create random virolog designs, pass it through the lettuces flow, then convert the output back into something that is behavioral virolog, and then use something like the formal verification features in users to check if the virolog we started with and the virolog we got out at the end are formally equivalent. So you can go to clifor.at slash iStorm and browse the documentation I wrote. There's a little bit of warning here. It's a reference. It's not like an introductory textbook. So if you don't know anything about how FBJs work internally, it might be a hard read. Also, it's actually not very well structured, unfortunately, but it's not very long. It's just a few pages. So my recommendation, if you really would like to know how these FBJs work and what this little bit means is to just read the entire thing once and then you have an overview of what is and for example, most of the interconnect is explained on the page for the logic tiles and things like PLLs and the over nets are explained on the page to cover the IO tiles. But it's really small and you can read it in maybe an hour or two, so it's, I think, not so bad. So the things provided by Project ISTOM besides the actual tool, the documentation provided us is a written documentation that gives you an overview. Then there is an auto-generated HTML documentation that gives you the reference, what each bit exactly means. And there is also an auto-generated ACI database that can be used in other tools like Arachne PNR to do something with this kind of FPGAs. And here are a couple of screenshots from this documentation. So on the lower left you have some of the written documentation that covers, this is actually from the IO tile and you see the column buffer control bits that are used for the global nets and stuff like that is documented here. Then the two screenshots with this wonderfully colored tables, these are the auto-generated HTML documentation where we document the function of each and every individual bit. And most of them in more than just one way. So we have in this case some matrices that can tell us which nets can be connected to which other nets and what bits are used for that. And here on the upper right you actually see for one logic tile the entire collection of bits we have reverse engineered. So you see there are some grey areas and as far as I can tell it's not the things that I have missed but these bits are just not used. I can't be sure, of course, but I didn't manage to create any very long design that would use those bits so I think it's a pretty fair guess that they are actually unused. And on the bottom right you see a part of the interconnect documentation and you can see things like this interconnect lines are pair-wise crossed out and stuff like that so it took us quite a while to figure out all these details. Yeah, so that's project ISTOM that's the low-level stuff and of course it's very interesting to just see how the FPGA works and to know what each and every individual bit does but this doesn't really give us something that we can use for like everyday design work with FPGAs. So partur-rachne-pna this is the place and route tool that Cotton Seed wrote but this now takes this Blift Netlist and converts it into one of those text files so it performs essentially the disoperations here it instantiates IO cells and clock buffers this is more like a convenience feature but it's something that is quite useful for place and route or low-level implementation tools to do something like that it packs looks and carry-logics and flip-flop instances in logic cells because the architecture netlist has individual look-up tables and carry-logic blocks and flip-flops and we need to figure out how we can fit them into this logic cells then we place the design this is currently done by Simulated and Nealing only but we are working on the flow that would use like a first step that that does an analytical placement and then we refine it using Simulated and Nealing then of course it routes the design and then it dumps the FPGA config so how does this input netlist format really look like this Blift file we use the same cell types that they used by the latest tools themselves so we stick to the I-Sport the technology library which allows us to mix our own tool chain with the lettuce tool chain and for example use our front-end and then go into the lettuce back-end or vice versa Blift is a pretty easy file format and you see a simple example here.model it's just a statement Blift calls it model but in virology you would say a module and then you have a list of inputs and outputs every net that are used but not declared as inputs and outputs are just internal wires and in this case the entire design is just a simple lookup table a single SBLoot4 with this four inputs and one outputs and here you see our non-standard.param statement that is used to set the lookup table for this particular look for instance but you can also put additional input files into the I-Storm flow for example you can give it a physical constraint file as I mentioned already that is primarily used for IO placement and once again we try to do something that looks very similar to the file formats used by the lettuce tools so it's easy to switch between back and forth between our tool chain and the lettuce tool chain you can also use placement route script this is a more experimental feature that is in development right now where you can manually specify what steps should be taken in which order and also give the individual passes additional parameters and with that we have already an experimental flow where you use the analytical placer and you also together with Arachne PNR but that's not actually what I would like to do in the end with analytical placement because the analytical placement in Joses doesn't really know how the FPGA looks like and that there are only certain places where a RAM tile can go for example the output format of Arachne PNR on the other side of course this I-Storm ASCII files and as I've said they can't be converted to the things that you would like to do with them with the I-Storm low level tools so of course you can also create additional outputs like a placement file that contains all the placement that are generated automatically during placement or a brief netlist of for example the packed design because this is something that you might want to investigate so this is the second part of our flow Arachne PNR now we can take and implement it on the chip so theoretically we could already create very minimalistic designs but it's not how you would usually like to do it so in the third part we are going to look at Joses and Joses as I've said is my main project it's the tool that can actually take HDL designs written in Verilog and you can use them to whatever you would like to use in the end so this is a small example of what you can do with Joses you can read various file formats and most importantly you can read Verilog and in this case Verilog is pretty much everything from Verilog 2005 so it's pretty much up to date however as you can see there is no VHDL front at the moment there are people who are saying that they want to work on that and I'm very curious to find out what we will see in a year or so you can write various file formats of course you can write Verilog which can be interesting for things like post synthesis simulation but you can also write Blyth you can write Adif which is very important if you would like to go into a commercial backend because they usually use and some other format you can of course perform RCL and also logic optimization some of the optimization is done in Joses directly and some of the optimization uses an external tool from the Berkeley University called ABC which is used for low level logic optimization and you can of course map designs to target architectures like certain FPGA architectures or ASIC cell libraries and you can also perform former verifications which is actually the thing I maybe spent most time on working some have said that Joses is something like LLVM for hardware I really like this idea and I like this analogy but there are a couple of projects at the moment that try to become the LLVM for hardware so I can't really claim that title yet so what kind of flows do really exist of course there are many more flows that are implemented with Joses but most of them are like one person building a custom flow which is part of their PHD thesis work or something like that so these are the flows that are like more general and something that you actually might want to use as it is there are two ASIC flows that use Joses as frontend there's Qflow and there's Coriolis 2 and both of them have been already used to tape out chips for Qflow I also know that people have taped out commercial chips with that so this is something that is actually in use and it's not like thought experiment and theoretically it's actually done then of course there is the synthesis for the FPGA which is the flow I'm talking about right now and then there is a flow for Xilinx 7 series FPGAs but with test flow we don't have any open source implementation back end to do things like place and route so you could use Joses to do the synthesis but then you would still need to use something like Xilinx Revado to do the actual implementation and of course there are two formal verification flows and I think the most interesting one is Joses SMT BMC that's used to perform formal verifications using standalone SMT solvers by writing files in SMT2 format and SMT2 is the format that is used for the competitions for SMT solvers so this means you have no vendor lock in forever because every SMT solver that is going to be written will support the SMT2 file format because they want to compete in these competitions so what does Joses synthesis script look like and it's something like this here you have a usually a generic part that is just read this design files and then some kind of synthesis command there is here the very generic Synth command and then you have a target specific part that does the mapping to the target architecture in this case an ASIC cell library but of course this looks very much like it looks when you look into commercial ASIC flows they usually look quite similar that you have something like a tickle script and it reads a few very log files and then it calls one command that does the magic synthesis part but in Joses this Synth command is actually a script itself that is just a sequence of other commands and when you look into the help message for the Synth command then you see this script that is actually used behind the scenes and some of those commands like PROC or OPT or FSM or memory are themselves just sequences of other commands so it's quite easy to look at this and actually understand what steps are taken in sequence to turn a high level description of a design into a low level net list for the given target architecture and it's of course also possible to do things like stop synthesis at any given point here and then dump this intermediate net list and see what's going on as I've mentioned already former verification is something that is very important for me so I had to have a slide here about different former verification methods that can be used with Joses, there is a built-in SAT solver that can be used to answer simple questions like is there any sequence of N time steps where in the end the signal A is high and the signal B is low and then it will try to find such a sequence I actually used this quite a lot when doing larger FPGA designs and you have to instrument something like an on-chip debugger and you only can have so many signals that you look at in your on-chip debugger so you end up with debug trace that says something like oh this signal is high and this signal is low and that time step you look at this and you wonder how is this even possible I don't see how this is possible and usually you would need to re-synthesize the entire design and add more signals to find out what happened to those signals and end up in this state but with this technology you can just take the design and say I have observed that these two signals go to this state what can cause this and it will give you an answer there is a large framework for equivalence checking which is very important if you do things like writing a synthesis tool because you would like to make sure that the output of your synthesis tool is formally equivalent to the input so I added that to property checking using meter circuits with the built-in solver and with external solvers like an ABCDA solvers that can be used for that and of course there is this uses SMT, BMC flow that I mentioned before so this is the flow with these three tools we can implement everything we we need we can build designs so how do we do this we can build the development part and luckily there are a lot of development parts available so from letters there are a few ones but there are also a lot of open hardware development parts and I'm not sure what's the percentage of them that have been inspired by the availability of this open source flow which of those have been planned already before I think but in the lower left corner you see the ICO board and the ICO board is actually a project I am involved with so I'm going to use that for the demo this is the ICO board it's a Raspberry Pi hat featuring the 8K FPGA and it supports up to 20 P-MOD parts when you use ICO X extension spores that are connected so in total you have almost 200 IO pins on the Raspberry Pi with that and I think this is something that can be useful even if you're not really interested in an open source FPGA tool chain so there are a couple of applications of course you can just make an intelligent Raspberry Pi IO expander that does a little bit more than just exposing IOS you can use the Raspberry Pi as a network enabled programmer and debugger it's quite useful and one more idea that I like very much is you can actually create HDL code on the fly, on the Raspberry Pi and synthesize it on the Raspberry Pi and program it into the FPGA without going to any external workstation that does the synthesis and bitstream generation step for you so we've built a small demo SOC and I have two motivations for that the first one is I would like to convince you that this tool chain can actually be used for non-trivial designs and not just small hello world examples and the second thing is this is a very small FPGA so I would like to convince you that even with something that only has 8000 Lutz you can do interesting things so my demo design here is a system on a chip uses only about 50% of the logic resources on this FPGA so it could also be very interesting as a basis for other projects because they still have half of the device for whatever you would like to add and it includes a full feature 32-bit processor that's compatible with the RISC 5 instruction set so you can use GCC tool chain and stuff like that to build programs for that and in this demo the Raspberry Pi is only used as a network-enabled debugger and to access the console part of the system on a chip it doesn't do anything else so this is a simplified block diagram of my demo you see all the thing in pink is something that runs on the FPGA itself and you see the external components are like the Raspberry Pi that's connected to this icolink core that implements a half-duplex bit-parallel communication link between the Raspberry Pi and the FPGA and icolink goes to various endpoints on the FPGA there is an on-chip debugger there is an endpoint that can be used to upload programs into the FPGA system there is a text console stuff like that there is a little bit system bus that connects all the components in the system like all those endpoints the internal block memory the SRAM controller that connects to the external SRAM we have a frame buffer here to talk to this LED matrix we have a GPIO controller to access all the GPIO pins we have of course the processor core itself and we have some logic for clock management so how do we synthesize something like this in this case we are just using a make file and here are the relevant make rules and you see the three steps that I had already on the first slide I use users to read the VRLock code synthesize it and write it into a blip file then they use arachne pna to take that blip file and the placement constraint file and to turn it into a text file, a text representation of the FPGA bitstream and then I use iSpec to convert this text representation into the actual binary file that can be programmed into the FPGA there are additional make rules when you look up the project to build the actual firmware and stuff like that using the risk file compiler toolchain and there are additional make rules for programming and there is a tool called icobrock that runs on the Raspberry Pi and we can either run it locally in that case SSH recipe is just SH-C so it's just using a shell to start this program locally but SSH recipe can also be just a call to SSH to connect to the Raspberry Pi and icobrock always reads from an input and output so I can use just standard in and standard out for things like use this binary and write it into the flash in this case I also mentioned the on-chip debugger core so you can just hook it up to any nets you would like in your design and essentially you get a logic analyzer you can write a few lines of variable code to define your trigger condition and to define what clock cycles you would like to keep in memory and what clock cycles you would like to ignore and with the default environment I have there is a make target called make debug that just connects to the Raspberry Pi via SSH and downloads a value change dump file that can be displayed in a program like GTKWave yeah running applications on the system on the chip looks like this when it first starts the boot loader running and the boot loader displays this image of a floppy disk on the left because that's what I think a boot loader should display then a couple of example programs that I wrote and they just use this text console to talk to the boot loader and writes a text representation of the hex content to the boot loader and that writes it into the sram and then executes it and I'd like to try that let me see something like that let's just reset boot that's taking too long that's exactly what I wanted to avoid great ok so luckily I didn't suspect the software problem so now we should see the boot loader ok and let me just make this a little bit smaller so and then let's for example do this here so and now we have, hopefully started something unfortunately I can't go on because I don't have it here ok so now we have this Christmas tree blinking let's go back to the FPGA directory and say make debug so now we've downloaded 256 cycles of debug data from the built-in debugger and we can just play this so what's now well that's great ok second time it works so now we have downloaded some debug data and in this case I have configured the built-in debugger to monitor the memory boost in the thing so we can see the instruction fetches and every now and then probably a non-instruction fetch ok they are all instruction fetches 256 cycles it's not so much ok so we can see this is I think really a non-trivial system and shows that we have a toolchain that can be used to do real world stuff and not just very simple hello world like things good so how does it compare to the commercial flow so there are two commercial flows available from Lattice they both used Lattice proprietary back-end the SPT back-end but one of the two flows is using Simplify Pro as synthesis front-end and the other one is using Lattice LSE as the synthesis front-end and we are comparing that with Joses and the Rachne PNR first a couple of notes for this I am using a version of the Lattice tools that is almost a year old and the reason is that I have wasted a day of my life trying to activate the license for a newer version and failed so I am not sure how it would compare with the up-to-date version of the Lattice flow and the second thing is that Joses might not be so good when you look at logic optimization and what you can do with the Lattice but Joses is astonishingly good with inferring memories from behavioral code in many cases better than many commercial tools and this is also the case here so when I used my design as it was with the Joses Rachne PNR I had something like 22 block rooms but the other two tool chains had also 7 and 8 block rooms like here and there were a thousand lookup tables because they fall back to using the logic resources to implement those memory resources because they didn't know how to do things like infer memory with byte and ABER for writes or infer memories with complex read and ABERs and for many architectures this is not a problem to have an output register on the block ram so if you don't correctly infer that read and ABER you just can't use the block ram resource anymore so instead of rewriting the entire design so it works on all three tool chains I made a stripped down version that's not using the frame buffer because block ram resources there make some troubles and I also stripped down the internal block ram so if you let's say you have a lot of like four words or something like that so it would be implemented in logic in both cases you can see in terms of packed logic cells the uses rachne and pnr flow is a little bit more compared to the other two flows but it's not like the world we have almost 500 carry cells used, and the other flows only use 372. Because I'm too aggressive with instantiating carry cells, I oftentimes force a very, very small logic path to one side of the carry cell and another logic path to the other side of the carry cell, and I end up with a higher logic utilization. So that's the main reason why we have this difference here. But I think it's not the world. What I find quite interesting is that synthesis is more or less the same time for all three flows. Let this LSE is actually a little bit faster in this case. But the implementation time is much, much smaller with arachnipianis, or arachnipianis much faster than the proprietary backend. And a lot of this is because of constant time when the commercial tools are loading the chip configuration and stuff like that, and because we pre-cached it when you have a virtually empty design where I just don't know, connect an input directly to an output and nothing else, you can create a bit stream in under a second or maybe a second and a half. So there are a couple of links and if you would like to scan this and you get to the link for this presentation where all the other links are, the slides are already online on this location and I'll see if I can also link them in the proceedings online. But if not, just go to Clifford.at slash papers and then you will probably find the link to this. Yeah, so the people working on that on different parts, the list is of course incomplete and a lot of people who just contributed very small but very important things like small test cases that expose bugs is something that is always very, very welcome. And we also have an assembly here. So please visit us. We are on level one, so between the blinking area and live until made the left that's near where the podcasters are and where the 3D printers are. We have more apps on this thing that you can play with if you want. And we are also going to do workshops today, tomorrow and the day after tomorrow at 1900. So if you'd like to have a hands-on experience with this kind of flow, then please come to our desk and register for those workshops. If a lot of people would like to see this, then we will probably schedule more workshops. Yeah, and we also give away iCoupboards if you have a cool project that you think would be nice to demonstrate what the iCoupboard can do. Then we are all fired and we'll give you a board. Yeah, thank you. All right, so we have a good 10 minutes of questions and answers time left. So if you have questions for Clifford, please come to one of the microphones in the hall. So everybody, even the people watching the video or the stream can hear you. And while you are lining up at the microphones, we are going to start with a question from the signal angel, please. Thank you. Richard Ian wants to know, he has a question about partial reconfiguration of FPGAs with higher amount of gates. Just the ICE letters series have internal configuration ports, like the Sylings FPGA do? Short answer, no. There is nothing that it can do for partial reconfiguration. However, there is an internal board called warm boot that can be used to reconfigure the entire FPGA from the FPGA. So it has two select pins and one trigger pin. And if you assert the trigger pin, then the two select pins will specify which of up to four bit streams will be loaded in the FPGA. So this is possible, but you can't partially reconfigure a device while it's running. Okay, all right. Then we are going to go ahead with mic one. You said when you first started, you got some emails about the IP. Have your relations with Lattice improved since then? Oh, this was not from Lattice. This was just from a random guy, who I don't know, saw it on Hackaday that I have done this and apparently took it very personally and thought I am after his IP and so he sent me an email and actually wrote that I should go to jail for what I did. It was quite an interesting experience. Okay, so we're going to mix in another question from IRC or Twitter. Chris wants to know whether the error messages are comprehensive. For example, no resources left or clock tree is not feasible. That's a good question. I think for all stages of the flow, the error messages could be better. I know it in particular for Joses and Joses, there's a lot of room for improvements for things like the input is not actually very low code. Usually you just get syntax error in line so and so and then maybe it's plus minus five lines because that's how parsers are. So the error reporting is not very good, but usually you get an error that with at least some experience you can track back to the problem. Okay, perfect. Mike, five please. Yeah, I would like to know a little more about VHGL support. So you mentioned it shortly, but is there a schedule when VHGL will be supported? No, at the moment there is someone working on it, but I think there is no code yet. There are two ideas how to support VHGL. One is we could write a new VHGL frontend and the student who is interested in writing a VHGL frontend is going to follow this approach. The other possibility would be to use some kind of VHGL to Verilog translator. And there is an interesting project that is part of Icarus Verilog, which is VHGLPP, which is a preprocessor to convert behavioral VHGL into behavioral Verilog. And when you do that, you actually can't do that. You need to add more features to Verilog because the simulation models are a little bit different. But with synthesizer code, it should actually be possible to convert synthesizer or VHGL to synthesizer or Verilog. So maybe it would be possible to hack this tool to do that. But I'm personally not working on either of those because I'm totally happy with Verilog. But I think that's my personal preference. All right, another question from the interwebs. Mo2000 wants to know how powerful is your processor from the demo in terms of registers and memory? Okay, so it's a RISC-5 processor and if you've never heard of RISC-5 before, it's a really, really cool project that aims at creating an open instruction set architecture that is free of any IP claims. So you can implement powerful processors with that instruction set architecture. The processor I have here is the Pico RV32. It's a project of mine and it's not very powerful because it's optimized for size. So here I think it's less than 2000 lookup tables on Xilinx 7 series, which is my prime target architecture for this chip in the smallest configuration. It's smaller than 750 lookup tables. So it's a really, really small processor, but it will take four cycles approximately for each instruction. It varies a little bit. On the good side, you can clock it with up to 400 MHz. So a lot of FPGA processors only go to something like 60 MHz and it evens out a little bit. RISC-5 is a 32-bit instruction set and regarding the registers, it has 32 general purpose registers, 31 because one is a zero register that always has zero and writes to it, I ignore it. Okay, all right. We still have time left, so we're going to go over to mic 4 with the next question. Yeah, I'm totally happy to see that such an accessible and open project for teaching at children's school or in the classroom, how our modern day process works from the specification of the processor to the output pins and it allows for a very cheap way to really understand this, to teach this. This is awesome. And I'm wondering, you mentioned that in the interest of users, especially this verification and I wonder whether this can be shown on the level of the processor you mentioned. Is that a real size where you can say, oh, my output pin on the processor went to high and low and can you verify on that size? There are certain verification tasks that I can run on my processor. Generally, processors are hard to formally verify because there is this huge divergence of control flow you inherently have on the processor. But there are things that I do, like as I think mentioned, the processor is configurable, so there are features you can turn on and turn off and they have a formal proof that says when I have two sets of features and I only look at sequences of instructions that don't let the less powerful feature set process or trap, then the more powerful must always have the same behavior. And this is a kind of proof that I can actually do with Yoses right now. Okay, before we go to the next question, just a quick ask to the people in the room coming in or leaving, please be as quiet as possible so we can finish the Q&A. Mike, please. I want to say thank you very much for doing this work to you and to Cotton Seed. I think this is the equivalent of the first version of GCC, but for hardware. So thank you very much for that. Thank you. All right, then we'll just stay with Mike Fyfe. Yeah, great project. But what about timing validation and timing during place and route? Yeah, right now none of our processes are really timing driven. There are some very weak timing driven optimizations on the high level stuff. Just know it's better to do this structure wide instead of deep and things like that. Right now the place and route stuff is not timing driven because we are still working on creating timing models. But this is almost finished. There are some technical difficulties. I think it's not the right moment now to discuss them, but I invite you to come to our assembly and I would be happy to talk about it. All right, then we're going to give the people who are not able to be in the room another chance to ask. Thank you. How does Lattice think about your open source flow? Are you in contact and what's coming next? Yeah, I don't know. So if anyone from Lattice is here, please see me. I would like to reach out to Lattice as soon as I have a working timing flow because that's the one thing that's still missing right now. And in my experience with all these projects, with yours and all the other stuff, whenever I approach some kind of commercial entity, they just don't believe that I can do what I say I will do. So I would like to have a complete flow that is really production ready and then say, here it is, maybe you would like to work with me together to improve on it. Okay, two more minutes. So to get as many questions in as possible, please make it short and precise. Mike, too, please. Hi. Hello. Do you think it would be feasible to design and fabricate a independent FPGA that would be compatible with this bit file format using open macro libraries? I think it would be possible, but it would be not really much harder to just make your own FPGA design and use these tools and create a database similar to the database we are using here and things like that. And there are actually projects going on right now where we're thinking about doing stuff like that, creating our own FPGA. So for me, this is, of course, interesting to really have support for an FPGA, but it was also important, so I can just show that my tool chain can deliver. Over 10 years ago, I tried to approach some ISIC companies and convinced them to build an open source FPGA. And essentially, all they told me is it's completely impossible because we will never have the open source tool chain. Now we have the open source tool chain, so I can go back to that and see if we can get an open source FPGA fabricated. Okay. And I think our last question is coming from someone watching the stream again. Actually, I have two. One is, can you run Oberon OS? And the second one is, would you think it would be possible to leverage your work on the FPGA device to reverse engineer other devices? How would an approach look like? I looked into the Oberon HDL designs. I can process them with VRHelog. In the default configuration, they would like to use multiplier primitives that are silent specific, so that would be something that would need some changes, but it would be possible. And the 8K FPGA, I think, should also be large enough for the Oberon thing. I didn't really get the second part of the question, but I think we are out of time anyway. Yeah, but you shared your contact details, so people here who still have questions and also people from the Internet can probably get in contact with you. So thanks Clifford for the talk. Thanks for the people asking. Thanks for having me.