IRC logs for #openrisc Friday, 2016-05-20

--- Log opened Fri May 20 00:00:14 2016
zumpdoes anyone know about hw/sw co simulation08:00
SMDwrkin terms of openrisc?08:01
zumpin general08:04
SMDwrkI have something like that at work, but I don't know if this could be helpful08:05
zumplets say you have some RTL of some core i.e a uart. is it possible to convert that to C, and then use it in firmware as some static lib such that "fake" register writes in firmware could produce the same functionality (tho much slower of course)08:07
SMDwrkIs verilator what you need?08:12
SMDwrkit converts verilog to c and then you can use C model of your core08:12
zumpis it a simulator.. or just a compiler? cause a cycle accurate simulator would be slow :(08:15
SMDwrkit's a compiler08:32
SMDwrkbut I don't know for sure (=08:33
SMDwrkat least it's faster than iverilog08:33
olofkzump: It's surprisingly fast. Orders of magnitude faster than event-based sims08:40
zumpwhats the difference btween verilator and carbon?08:42
SMDwrkolofk: I can't run verilator with fusesoc btw, have you seen that problem?08:42
olofkSMDwrk: Haven't seen that one. Which version of verilator are you using?08:43
olofkahh.. wait.. it's regarding $fflush. Hmm... I remember there was some problem with that now08:45
SMDwrk apt-cache policy verilator08:45
SMDwrk  Installed: 3.856-108:45
SMDwrk  Candidate: 3.856-108:45
SMDwrk  Version table:08:45
SMDwrk *** 3.856-1 008:45
SMDwrk        500 trusty/universe amd64 Packages08:45
SMDwrk        100 /var/lib/dpkg/status08:45
olofkIf you can, I would recommend you to update to a newer version of verilator08:47
SMDwrkOk, I'll check that at home on arch instead of ubuntu08:47
olofkSMDwrk: Otherwise, I think you can do a quick hack and remove the argument to $fflush in on line 275 in uart_transmitter.v08:51
SMDwrkzump: 2.509:04
wallentozump: carbon and verilator are similar09:20
zumpwallento: so the RTL model can't run in real time? :(09:21
wallentoI heard someone saying verilator was significantly faster09:21
wallentoonly if it is sufficiently small09:21
wallentoif its a small controller and its target frequency is like 50 MHz, it can also run in real time09:21
wallentobut once you start talking about adding a processor its much much slower09:22
zumpwallento: well what i want to do is write a UART.. and then compile it and deploy it to some microcontroller. and then write the microcontroller firmware as if actually exists in silicon. do you think thats possible?09:25
SMDwrkyou want to run verilated model on mcu?09:26
SMDwrkWhat kind of controller are we talking about?)09:26
wallentoThat won't run in real time09:30
wallentowhy do you need it to be in real time?09:30
zumpwallento because i want to write the real FW before the chip is taped out09:35
olofkzump: That doesn't mean you have to run it in realtime09:36
SMDwrkzump: why not using fpga?09:36
zumpour design is too big for an FPGA :)09:37
ZipCPUzdump: Your UART design is too big for an FPGA?09:37
SMDwrkUse bigger fpga ;)09:38
ZipCPUCome on guys, this is ridiculous.  If you can stick a micro-controller and a UART controller in a Spartan LX4, the problem isn't the size of your FPGA.09:39
zumpThe UART is just an idea for a proof of concept.. Im not a HW guy so it seems risky for this design to be coded up without firmware beeing proofed for it. Im just wondering what the current solutions in EDA are for it.09:39
zumpbasically, i cant use an fpga.09:40
ZipCPUzdump: It doesn't take much of a budget to learn ...09:40
SMDwrkthen run rtl through verilator and test your firmware there: actual emulatuon speed could be in kHz but what's the problem?09:41
zumpSMDwrk: so i can "hook in" firmware into whatever is produced by verilator?09:42
ZipCPUzdump: It may depend upon what you consider firmware.  Are we talking ROM code, microcode, or something else?09:44
SMDwrksure, but things could not be as easy as it sounds: you also have to write some wrappers and etc to get things working09:44
SMDwrkfusesoc can run openrisc simulations with verilated sources: I think they use jtag to upload code, but I'm not sure09:44
zumpZipCPU: writing registers, handling interrupts, etc..09:45
ZipCPUzdump: Okay, very low level software then.  Do you have Verilog available for the CPU you wish to deploy this firmware for?09:46
_franck__zump: you can run any firmware you want if you verilate your cpu's RTL09:46
zumpI don't want to do the entire CPU.. i want to verilate a specific core which would be on the same SoC as the CPU, and then read/write the verilated core using code on the CPU (though underneath, it will just be instructions, not silicon)09:47
_franck__where would you run the CPU ?09:49
ZipCPUzdump: If you don't wish to verilate the entire CPU, then ... are you hoping to write, run, test the firmware on a different verilated CPU?09:49
_franck__I mean your firmware is executed by the CPU so if you don't simulate the CPU ... ?09:49
zumpin the actual SoC. that exists. but doesnt contain the new core as yet.09:49
zump*CPU in the SoC that is..09:51
_franck__so you need some sort of bridging between your hardware and some simulated software09:51
ZipCPUzdump: Let's see if I can summarize the details to this point: You are working to develop the firmware for an existing CPU.  You'd like to create a new/better peripheral for this CPU, and want to make certain that the firmware works before the CPU with this peripheral is taped out ... right?09:52
_franck__ibut without any core to communicte how would you do that ?09:52
zumpZipCPU: yeah sounds about right..09:52
zumpexcept its really a core on a SoC, rather than a peripheral for a CPU09:53
ZipCPUzdump: By core, you mean that it is going to be internal to the SoC, rather than an external peripheral, right?09:54
_franck__zump: but if your CPU is not tapped out, not simulated and not in a FPGA...where it is ?09:54
zumpin an existing ASIC09:55
zumpits just a rev that doesnt have the new RTL in silicon09:55
ZipCPUOkay, this is starting to make sense.  Do you have any form of simulator that can simulate your ASIC?09:55
zumpno.. but we are looking at getting Carbon.09:57
zumpbut ive seen a demo of that. and it seems slow. I would like something that operates in near real time09:57
ZipCPUzump: Okay, but you've got the previous version of the ASIC, right?09:57
zumpZipCPU: yes09:58
ZipCPUSo, if I understand correctly, what you'd like is an external peripheral to the real/current ASIC that you can develop against, right?09:58
ZipCPUIf yes, then you still have some options.  One classic one would be to connect a piece of reconfigurable hardware to your ASIC.  You could then develop on that hardware and get your core and firmware working.  The difficult part here would be that the external interface between the ASIC and the core would be ... other than true.10:01
ZipCPUDid I capture that right?10:01
zumpthat's true10:03
zumpi dont think the hw guys would like that though10:03
ZipCPUzdump: Ok, if you don't want to develop on real hardware connected to a real processor, and you don't have a simulator for your real processor to enable you to develop on simulated hardware, then where do you wish to place the boundary between real hardware and your development environment?10:06
zumpIn theory, my verilator idea should work. Compile to static lib, link with firmware. Hack around with a thread that polls for a variable in the model and go into an interrupt handler if asserted10:06
zumpon the chip itself? :P10:07
zumpsomething like that isnt *too* far fetched is it? I should try it10:07
zumpIs there some 'hello world' RTL out there?10:07
zumphah.. im not the first with this idea10:10
ZipCPUzdump: So ... you want to develop real software, running on real hardware, that will communicate with a Verilated core also running on that hardware and act like ... a simulated core.10:10
ZipCPUI'll say this, it's not how I've ever used Verilator before.  Do you have any experience or background with Verilator?  Have you simulated any cores with it before?10:11
zumpZipCPU: nope..10:12
zumpZipCPU: so you're saying its not a "functional" simulation like I'm thinking, and it's more like a RTL simulator like quartus II like I used at university?10:13
ZipCPUI can't speak for quartus II--but I thought it was a development environment for an Altera FPGA, not a simulator ...?10:14
ZipCPUVerilator allows you to calculate logic outputs given logic inputs.  You still need to provide those logic inputs, however.  One of the most fundamental inputs you will need to provide is a clock tick.  Without ticking the clock, nothing will happen.  (It doesn't go and run on it's own, although you could create a separate task and communicate with it via some form of IPC.)10:15
zumpyeah.. so I was thinking the verilated model could run in its own thread.10:16
ZipCPUIt's doable.  You'll be spending a bit of time writing your thread communications though10:17
zumpexcept i have another problem10:17
ZipCPUGo on.10:17
zumpand that's simulating data transfer10:18
ZipCPUYou mean, something like a DMA data transfer?  You can't do that via a piece of shared memory?10:18
zumpThe HW guys use some sort of system called AXI. I have to somehow remove that in each verilog block and replace it with, you know, memcpy.10:18
ZipCPU<Cradles head in hands and weeps>10:19
zumpthats probably my bigger problem...10:19
zumpeach core is heavily dependent on signals from system backplane10:20
ZipCPU<Still drying eyes>  As I understand AXI, it is a bus interface similar, but different from, the wishbone interface I have become accustomed with.10:22
zumpyeah its probably the same. i recall coming across wishbone/axi bridges10:22
zumpso you were able to simulate wishbone in verilator?10:22
ZipCPUSure!  Simulating wishbone is easy.  I wish every problem were that easy.10:23
ZipCPUWould your Verilator simulator have access to and command/read real hardware wires, or would it be simulating the actual hardware interaction as well?10:23
zumpI had a look at the rtl before, and every core uses the 5 axi slave signals.. i have no idea how i would handle that in the verilator simulation.. maybe i could write some wrapper code to generate the correct AXI transactions? haha10:26
zumpZipCPU: How do you provide the correct IO for wishbone bus signals?10:26
zumpin verilator10:26
ZipCPUSo my big project can be found at,zipcpu  This is what I've been investing my time into for a while.10:28
ZipCPUIn that project, in the trunk/bench/cpp directory, you'll find a program called 'zippy_tb.cpp'.  This is the code for my Verilator simulation of my soft-core CPU.10:28
ZipCPUWithin that file, you'll find code for wb_write(addr, value) and wb_read(addr).10:29
ZipCPUBasically you set the CYC and STB lines high, tick the Verilator model, drop the STB line when the STALL line is low, and then wait for the ACK line to go high.10:30
ZipCPUWhen ACK is high, read the data off the bus and drop the CYC line.10:30
ZipCPU(Oh, did I mention that when you set the CYC line, you also need to set the address, whether or not you are writing and if so the data lines ... and I think I've just about got it there.)10:31
zumpok, so in your software TB, you're faking a hardware transaction?10:31
olofkzump: What you need then is a BFM (Bus Functional Model)10:31
olofkI have written one for Wishbone10:31
olofkIt allows you to do reads and wri10:32
zumpolofk: got a link?10:32
olofktes from a testbench10:32
olofkBut that unfortunately won't run in verilator10:32
zumpso if my scheme is to be successful, I would have to follow the AXI protocol while ticking the model correctly10:32
ZipCPUIsn't that what you really want?10:33
olofkzump: Do you know if it's the full axi4, or axi4lite?10:33
zumpprobably light10:33
olofkBecause I think there are several open source BFMs for Axi4lite10:33
zumpbut the BFM is still RTL...10:34
olofkYes, but it will contain methods that you can call from sw10:35
olofkInstead of implementing the protocol in sw, which is probably more awkward10:35
zumpso a BFM is basically an implementation of a bus protocol so i dont have to write it myself?10:36
olofkYes, that's a quite accurate description10:38
olofkWith API calls10:38
olofkI think your problem is quite interesting. I have been having similar thoughts for some time10:38
olofkLike using a high-level CPU/SoC simulator and only exchange a single peripheral core for an RTL model10:39
olofk_franck__ did some cool experiments in that domain for OpenRISC some time ago10:39
ZipCPU(olofk: I got lost at the task keyword in your BFM ... I've never used 'task's before.)10:40
zumpI need to find a simple AXI slave RTL and do proof of concepts with it using verilator10:41
olofkZipCPU: Tasks are allowed to consume time, while functions aren't (very similar to vhdl procedure/functions)10:41
olofkZipCPU: task can also have as many inputs and outputs as you like, but doesn't have a return value10:41
shorneolofk: I kind of figured out another one of the gdb issues I was having.  next onto varargs10:41
ZipCPUYes, but ... how do they turn into synthesizable HDL, or can they only be used with the simulator?10:42
olofkzump: There's one thing to be aware of then. Verilator assumes that the code is synthesisable. My wb_bfm isn't10:42
olofkhaha. That also answers ZipCPU's question :)10:42
olofkshorne: Cool. Sorry for leaving you alone for a while in the gdb jungle.10:43
ZipCPUOkay ... so a Verilog task would roughly be the equivalent of my C++ wb_write and/or wb_read calls.  Neither is truly synthesizable.10:43
shorneits ok, I ended up having to debug gdb in gdb, and finally figure it out10:43
olofkshorne: I think for varargs, we should start pushing to stack when argnum >= TYPE_NFIELDS(func_type))10:44
zumpolofk: how come10:44
olofkZipCPU: No. I use my BFM with event-based sims (Icarus, Modelsim etc)10:44
shorneolofk: yeah, I was planning to look back in the irc log to get those function names you figured out10:44
ZipCPUolofk: But if zump wants to use Verilator to create his core, and if verilator only works with synthesizable verilog, how would a non-synthesizable bfm help him?10:45
olofkshorne: And func_type is defined like this "struct type *func_type = value_type (function);"10:45
olofkZipCPU: It won't, so I pointed out that10:46
olofkunless it's synthesisable of course10:46
ZipCPU<Reaches for the tissue again>10:47
olofkA third option (still going with verilator) would be to write a systemC wishbone model10:47
olofksystemC was created to model RTL stuff in C(++)10:47
zumpI found an AXI4 BFM10:47
_franck__olofk: zump : it's kind of what I did here:
olofkzump: Reading a bit more carefully, it only implements AXi4stream Master10:48
olofkwhich is not what you're looking for10:48
shorneolofk: yup for 'if (TYPE_VARARGS (func_type))'10:49
zumpdoes verilator support VHDL?10:50
olofkzump: Nope. Only Verilog and a subset of SystemVerilog10:50
zumpDamn. some blocks are in VHDL10:51
zumpdo converters exist10:51
olofkzump: Is it pulpino you're working on? :)10:51
ZipCPUIt still uses tasks as well--which you can't use in Verilog either.10:51
zumpno..  i am working on something in bitcoin10:52
olofkah ok. Just had to ask, because pulpino is completely verilog except for a VHDL UART :)10:52
zumpah ok...10:52
olofkzump: Related to KNC Miner?10:52
zumphah.. no. just a bunch of geeky guys10:52
zumpsomewhere else10:52
zumpis it possible to convert from VHDL to verilog?10:53
olofkNot really10:53
olofkThere is unfortunately very limited support for VHDL in the open source tools, and even more so for mixed-language simulations10:53
ZipCPUSure it is.  I'll be glad to bill you my services.  How much do you need converted?  ;P10:53
olofkYour best hope would be Icarus Verilog, which is gaining more VHDL features all the time10:54
shorneolofk: got varargs pushed to stack now too. just one failure in gnu_vector10:54
olofkBut... if it's just a small UART, I'm not convinced you need the speed of verilator. You could use icarus or modelsim instead10:54
olofkshorne: Awesome!!! So close now10:54
shornehmm, assertion failure...10:55
olofkzump: One way to do this that I have been thinking about is to build a testbench for your UART with a BFM, hook it up to a socket, and then send the register accesses over the socket from your software10:56
olofkI have been doing similar things before, and this is how we do JTAG currently10:56
ZipCPUzump: olofk: I've also got something similar running for my XuLA2-LX25SoC.  The Verilator runs in a separate process, and the control software can access registers, get interrupts, etc. over a socket.10:57
ZipCPUThat way I can use the same PC source code to interact with the Verilator code as I use to interact with the real XuLA2 board.10:58
olofkZipCPU: Which interface do you use with the real board?11:00
ZipCPUThe XuLA2 board connection is via the JTAG User function.  I made it work like a UART that could send and receive characters, and then compressed a wishbone bus interface to work over that.11:01
ZipCPUSince it was a basic character interface, it could also run over a TCP socket as well.11:01
olofkZipCPU: Aha.. a homebrewn solution11:01
ZipCPUIt's actually a 3rd generation home-brew solution, and I've got a 4th generation one that's not quite complete yet.11:02
olofkZipCPU: Have you seen the jtag_vpi backend in OpenOCD that _franck__ wrote?11:02
ZipCPUNo.  Care to tell?11:03
shorneolofk: all passing, but its a bit hacked11:03
olofkZipCPU: As we normally use OpenOCD as a JTAG proxy to talk with our boards, _franck__ wrote a driver that sends the commands to a socket, so that we can instantiate a small testbench component in our sims and use the full JTAG stack in simulations11:04
olofkSo for regular HW it's client->openOCD->JTAG adapter->(FPGA JTAG Core)->(Debug interface)->(CPU/Memory)11:05
olofkFor simulations it's client->OpenOCD->Socket->(Testbench JTAG BFM)->(Debug interface)->(CPU/Memory)11:06
ZipCPU<Browsing jtag_vpi code now ...>11:06
olofkshorne: All right! Good job.11:07
olofkshorne: Have you booked the ticket to Bologna btw?11:07
shorneolofk: I dont think I can make it this year. It would be good, but have other travel plans this summary11:08
ZipCPUolofk: So in my case, I run ZipDBG->DevBus->WB/stream Converter->TCP/IP->Verilator->stream/WB converter->WB bus->(CPU debug port/peripherals/memory, etc.) for simulations11:10
ZipCPUand ZipDBG->DevBus->WB/stream Converter->Jtag/Cmds->LibUsb->uController->FPGA JTAG->stream/WB converter->WB bus->(CPU debug port/peripherals/memory, etc.) for the real hardware.11:11
ZipCPUAny program that wishes to access the hardware needs only to understand the DevBus interface, and then it looks/acts/feels like the hardware wishbone bus interface from there.11:12
zumpthats a large stack11:16
ZipCPUzump: Well, it's really defined by the devbus interface.  Take a look at that here:,xulalx25soc in the trunk/sw/devbus.h file.11:19
ZipCPUI like to think that defines just about any bus interface you might ever need from a software standpoint.11:19
ZipCPUI built it to describe what I hoped would be a PCIe interface, but the backend has yet to be ported to PCIe.11:20
shorneolofk: latest gdb patch in case anyone interested
olofkshorne: Thanks. I'll give it a spin later on12:33
stolarWhere I can find a code/file responsible for multiplication system (I don't know if I translated it correctly - układ mnożący in polish, maybe in english properly it calls multiplier) in simulator or1ksim? I think it is related with Arithmetic Logic Unit in OpenRISC. Am i right? I need to know how to switch off this multiplier?14:58
olofkshorne: Getting 1 known failure with your patch on gnu_vector. Is that expected?17:10
shorneolofk: yes, I didnt look into the knowns17:39
shornealso I just found one issue when running full tests17:39
shornebasically with NARGS (varargs) its sometimes used for non varargs functions, so I have to check TYPE_VARARGS(ftype) too17:40
shorneI fixed it already, the main thing I am concerned about it my hack here:
shorneusually if you call a function like 'print myfunc(big_i)' 'big_i' will be a variable on the target.17:43
shornefor for big things we pass the arguments by reference (pointers in regs)17:44
shorneif big_i is on the target its fine, it will have a pointer17:44
shornebut if we call with 'print myfunc((big_i_type){1,2,3,4,45,56})' then the type is fabricated.17:45
shorneand we need to 1. trasfer the struct to the target, 2. put a pointer in the register17:45
shorneSo... we need to put it low in the stack. how?17:46
shorneI found some related failures in gdb.base/callfuncs.exp test fixed them (related to handling return as structure)18:06
shornebut then that broke another testing in gnu_vector (need to get all the edge cases correct)18:07
shorne~total failures was 440, just fixed a few more and rerunning18:34
shornenow down to 40418:41
shorneolofk: latest patch, 2 points I am not happy with (see fixme's in patch)
shornebut it works18:57
shornegdb test summary19:10
--- Log closed Sat May 21 00:00:16 2016

Generated by 2.15.2 by Marius Gedminas - find it at!