| --- Log opened Tue May 31 00:00:31 2016 | ||
| mafm | somebody here will probably will be able to do something about this... | 07:31 |
|---|---|---|
| mafm | http://orconf.org/ is a endless-recursive loop | 07:32 |
| mafm | redirecting to openrisc.io or something similar | 07:32 |
| olof | mafm: That's strange I'll look it up | 07:32 |
| olof | Yeah, it's supposed to be redirected to openrisc.io/orconf | 07:33 |
| olof | But that page doesn't seem to work | 07:34 |
| mafm | olof: it redirects back to orconf.org | 07:34 |
| olof | We need to get a proper website for orconf :/ | 07:35 |
| olof | If I just get a basic homepage somewhere I can point orconf.org there. Anyone? | 07:42 |
| shorne | olof: github pages with a CNAME? | 08:04 |
| ZipCPU | Are there any plans (yet) for the next ORConf? (I remember the name was going to change ...) Location, dates? | 08:13 |
| _franck__ | ZipCPU: 7-9 October in Bologna | 08:20 |
| ZipCPU | Thanks! | 08:20 |
| ZipCPU | (I have been, and continue to, dreaming of attending ...) | 08:23 |
| olof | ZipCPU: Stop dreaming and just go there :) | 08:27 |
| ZipCPU | Thank you olof for the encouragement. It'll be a trip across the sea for me, and I haven't done that in years. | 08:28 |
| olof | ZipCPU: Where do you live? | 08:41 |
| SMDwrk | Any invites needed? | 08:43 |
| SMDwrk | Or entrance is free? | 08:43 |
| olof | Entrance is free | 08:44 |
| olof | I really need to get that homepage going soon | 08:44 |
| SMDwrk | In that case I'd try to be there too | 08:45 |
| olof | Great to hear! | 08:48 |
| olof | Haven't done Altera synthesis for some time. Is there a way to ensure that I/O registers are pushed to the pads? | 09:20 |
| olof | I might be able to force it with a tight (dummy) timing constraint though | 09:20 |
| ZipCPU | Wait ... entrance is free?? There's no conference fee? | 09:26 |
| SMDwrk | I guess so | 09:27 |
| olof | ZipCPU: No, we want to keep it free to be as inclusive as possible | 09:27 |
| ZipCPU | olof: Then ... who pays for the venue? | 09:27 |
| olof | ZipCPU: Sponsors. For the venue, we have been lucky so far that the people at the location has been able to pay for it | 09:28 |
| olof | e.g. some faculty at the university | 09:28 |
| olof | And it's usually not that expensive to rent a conference room during the weekend for a non-commercial conference | 09:29 |
| SMDwrk | It's convinient to live in Europe btw ;) | 09:29 |
| SMDwrk | And what's about list of reports for the conference? Is it ready? | 09:31 |
| ZipCPU | Yeah ... it's the Europe thing I'm dealing with. On the other hand, if there's no conference fee, that certainly sweetens the deal tremendously. | 09:31 |
| SMDwrk | ZipCPU where're you from? | 09:31 |
| ZipCPU | I'm living in Virginia, U.S.A. these days. | 09:31 |
| SMDwrk | Oh | 09:31 |
| SMDwrk | Long trip | 09:31 |
| ZipCPU | Yup. | 09:32 |
| ZipCPU | I'm used to long trips--you know, to Colorado, Texas, but across the pond is ... more than I've done in years. | 09:32 |
| olof | ZipCPU: You're not going to the next RISC-V conference in Boston? I'm flying over for that one | 09:33 |
| ZipCPU | Not familiar with it. What would I look it up under, RISC-V? | 09:33 |
| olof | yes | 09:33 |
| olof | http://riscv.org/ | 09:33 |
| ZipCPU | set | 09:41 |
| ZipCPU | (Sorry ... typed into the wrong window ...) | 09:42 |
| kaaliakahn | olof: I am going to be at RISCV as well | 12:30 |
| kaaliakahn | ZipCPU: Hi, Are you the guy who has written an entire tutorial in VHDL? Please correct me | 12:31 |
| ZipCPU | Hello Kaaliakahn. No, I am not that person, although I am flattered that you think I might be. | 12:32 |
| ZipCPU | My only real claim to "fame", if it even be that, in this forum is that I've built a variety of wishbone cores, and that I've been working to try to create a "simple" 32-bit pipelined CPU. | 12:33 |
| kaaliakahn | ZipCPU: I have heard about ZipCPU. isn't that on github | 12:33 |
| kaaliakahn | great work | 12:33 |
| ZipCPU | I maintain it on opencores. I think there was someone who tried placing it on github at one time, but I can't comment on how well (or poorly) the code there matches the latest that I've been working on. | 12:33 |
| kaaliakahn | you can tell me what SoC buses like wishbone. I never understood the concept of a bus | 12:34 |
| kaaliakahn | and why a design needs one? What are your thoughts? | 12:34 |
| ZipCPU | A bus is very simply a means of transferring information to or from a particular address. | 12:34 |
| ZipCPU | If your SoC wants to talk to memory, it needs a bus. | 12:34 |
| ZipCPU | I like to add other things to the busses I work with, such as: SPI flash, SDRAM, block RAM, and peripherals, such as UART, PWM, GPIO, and more. | 12:35 |
| kaaliakahn | ZipCPU: cant you connect the two with wires like "wire [15:0] bus". Why is not having wires good enough? | 12:35 |
| ZipCPU | When I talk about a "bus", such as the wishbone bus, I am talking about address lines, data lines, and command lines. | 12:36 |
| ZipCPU | The address lines specify what/where you are talking to or about, the control lines specify whether or not you are reading or writing, and tell you when the transaction is complete. | 12:36 |
| ZipCPU | On the wishbone bus, there are two sets of data lines: one set going from the "master" (or the one controlling the bus) to the slave (the one responding), and another set of data lines returning. | 12:37 |
| ZipCPU | So, for example, suppose you wish to read from address 0x0103. (This is where I like to place my build date, although my address placement is definitely non-optimal ...) | 12:37 |
| kaaliakahn | ZipCPU: so you need two set of datalines not one on which both can communicate. Its like two way lane rather the one lane | 12:38 |
| kaaliakahn | right? | 12:38 |
| ZipCPU | You would set the address lines of the bus to 0x0103, set the CYC (bus cycle) line to indicate you wish to use the bus, and the STB (strobe) line to indicate the active portion of the cycle. | 12:38 |
| ZipCPU | Many off-chip peripherals use one set of shared data lines. These become hard to simulate within a chip, so I tend to use two. (I think the wishbone actually specifies two sets as well ...) | 12:39 |
| kaaliakahn | ZipCPU: How assigns the addresses to cpu as well as other peripherals? | 12:39 |
| ZipCPU | Continuing with my example, when the "peripheral"/slave/whatever, responds to your request, it will raise an "ACK"nowledgement line, and place the value on the data return bus. | 12:39 |
| ZipCPU | Gosh, that's a good question. I tend to do it by hand. | 12:40 |
| kaaliakahn | ZipCPU: If one peripheral has to talk to another peripheral, can it do that without the CPU? | 12:40 |
| ZipCPU | What a question! I'm working right now on a DMA peripheral that will need to command the bus separate from the CPU. | 12:41 |
| ZipCPU | Those peripherals that need to command the bus as you describe are "bus masters", the others are "slaves". The DMA peripheral I am working with is both master and slave. The CPU can command it via the slave port, but then it can command the bus via its master port. | 12:41 |
| kaaliakahn | I didn't get when you mentioned the build date? What is that and how it is coming into the context? | 12:42 |
| ZipCPU | Well, if I built my design today, the build date would be the 32'bit value 32'h20160531. | 12:43 |
| ZipCPU | Reading from one of the addresses on my peripheral bus, I can read that number back. | 12:43 |
| ZipCPU | It helps me to know when the FPGA configuration was built. | 12:43 |
| ZipCPU | Particularly, it helps me know that I did update the FPGA when I thought I did ... lest I keep trying to debug code that hasn't changed. | 12:44 |
| kaaliakahn | so this is the value not the address | 12:44 |
| kaaliakahn | or this is the data not the address | 12:44 |
| ZipCPU | Yes! This is the value, or data, at a particular address. | 12:44 |
| kaaliakahn | what address would you use? | 12:44 |
| kaaliakahn | and how do you find that out? | 12:45 |
| ZipCPU | I often use 0x0102. The address is hand picked. The build date is created as part of the make process. (A perl script writes it to a Verilog file, which is then included by the rest of the design.) | 12:46 |
| kaaliakahn | Correct me if i am wrong. What you are saying is that you want to download the bitstream onto FPGA and then read the build date from the bitstream? Right | 12:46 |
| ZipCPU | Yes. | 12:46 |
| kaaliakahn | which is the master and which is the slave in this case? | 12:46 |
| ZipCPU | I've only built a couple of masters. The CPU is the most predominant one, the DMA is another, the final big master I've built is a debug command/control port. | 12:47 |
| ZipCPU | The "version" that responds is from a slave device. | 12:47 |
| kaaliakahn | excellent job. Keep it up | 12:47 |
| kaaliakahn | May i take a look at the code? | 12:48 |
| ZipCPU | Sure! I have two SoC's that I've put together and posted on OpenCores. One is for the XuLA2-LX25, the other for a CMod-S6. | 12:48 |
| ZipCPU | http://opencores.org/project,xulals25soc | 12:48 |
| ZipCPU | http://opencores.org/project,s6soc | 12:49 |
| ZipCPU | The later was to see how small of a SoC I could create. The SPARTAN-LX4 chip is ... pretty small and limited capability wise. | 12:49 |
| ZipCPU | I was pleased that I could not only place my ZipCPU onto it, but also that I could build a bare-minimum, custom O/S and get that running on it as well. | 12:50 |
| kaaliakahn | but correct me if i am wrong. These cores don't have a CPU? RIght? | 12:50 |
| ZipCPU | The FPGA chips don't come with a CPU on them, that's what I did--placed a CPU onto it. | 12:51 |
| kaaliakahn | which cpu did you use? or you created your own? | 12:52 |
| ZipCPU | I created a "soft" CPU--an FPGA configuration that contains a CPU within it. That's what the ZipCPU is, a CPU that can be placed within an FPGA. | 12:53 |
| kaaliakahn | cool. Is it included in the above links? | 12:53 |
| SMDwrk | ZipCPU, quick question: you've disigned your own isa, right? | 12:53 |
| ZipCPU | Yes. | 12:54 |
| kaaliakahn | yes is for me or SMDwrk? | 12:54 |
| kaaliakahn | :) | 12:54 |
| SMDwrk | I think, both | 12:54 |
| ZipCPU | Sorry, yes to both. | 12:54 |
| SMDwrk | ZipCPU on what ideas your isa is based on? Or just simple risc | 12:55 |
| ZipCPU | The full ZipCPU core and support software, though, is a separate project. In particular, the GCC compiler port isn't part of either XuLA or S6SoC projects. | 12:55 |
| ZipCPU | The ISA was based upon the RISC concept, but not patterned after any existing RISC architecture. | 12:55 |
| ZipCPU | I had a mild familiarity with the 68k architecture from years ago, but the 68k supports many complex instructions that the ZipCPU never will. | 12:56 |
| kaaliakahn | ZipCPU: Is it single cycle, multicycle , pipelined ? How many stages? and where one could find its documentation? | 12:57 |
| ZipCPU | The ZipCPU is pipelined. You can find the documentation in http://opencores.org/project,zipcpu | 12:57 |
| ZipCPU | Please feel free to comment and provide feedback on it. | 12:57 |
| ZipCPU | There are 5 basic pipeline stages: Prefetch/instruction cache, decode, read-operands and apply offset, execute, and write-back. | 12:58 |
| kaaliakahn | great | 12:58 |
| kaaliakahn | can it run linux ? | 12:58 |
| ZipCPU | The execute stage includes up to four units: an ALU, a memory unit, a divide, and (I'm still working on) a floating point unit. | 12:58 |
| ZipCPU | There are a couple of things that keep it from Linux. One is a memory management unit, the other is the size of a byte. | 12:59 |
| ZipCPU | The ZipCPU is unique in that sizeof(char)=sizeof(int)=1 which is 32-bits. | 12:59 |
| ZipCPU | sizeof(long)=2, or 64-bits. | 13:00 |
| ZipCPU | I think if I had a proper memory management unit I could work through the sizeof(char) issue, but as I've described it for others: it would be an "adventure". | 13:00 |
| ZipCPU | (That's not necessarily a bad thing, it just ... would be an adventure.) | 13:01 |
| kaaliakahn | I talked to Olofk and he told me that its enough to have a CPU, Mem controller and UART to run linux | 13:01 |
| ZipCPU | I think he was particularly referring to the OpenRISC core. OpenRISC plus a memory controller plus a UART would run Linux. | 13:01 |
| kaaliakahn | yes exactly | 13:01 |
| kaaliakahn | why wont it run in ZipCPU case ? :P | 13:02 |
| ZipCPU | Are you familiar with what I am talking about regarding the "memory management unit" or MMU? This unit translates virtual to physical addresses ... | 13:03 |
| SMDwrk | zipcpu doesn't have MMU | 13:03 |
| SMDwrk | but you can compile linux binary which won't need mmu. uclinux? | 13:03 |
| kaaliakahn | what does it do and why is it necessary to run Linux? Any ideas | 13:03 |
| kaaliakahn | yeah i agree with SMDwrk | 13:03 |
| ZipCPU | I have not tried to compile uclinux. It sounds like it would be fun to do. | 13:04 |
| SMDwrk | Anyway sizeof(char) == 32 is stopper | 13:04 |
| ZipCPU | Not really ... just an adventure. | 13:04 |
| ZipCPU | I doubt it would compile immediately on the first try, but with some attitude adjustment ... I'm sure it could be made to work. | 13:05 |
| ZipCPU | ;) | 13:05 |
| kaaliakahn | true | 13:05 |
| SMDwrk | I wonder how many places there are in linux src with code like sizeof(int) / sizeof(char) | 13:05 |
| kaaliakahn | can you give a quick rundown on MMU? | 13:05 |
| ZipCPU | Sure. Remember when I described the wishbone bus? | 13:06 |
| ZipCPU | Everything on the bus has an address, right? | 13:06 |
| kaaliakahn | I always confused it with RAM reg [31:0] RAM [15:0] | 13:06 |
| kaaliakahn | right | 13:06 |
| ZipCPU | <chuckle> it is more than that. | 13:06 |
| kaaliakahn | for sure it is ;) | 13:06 |
| ZipCPU | The MMU translates, in hardware, a software's addresses to a different set of addresses. | 13:06 |
| ZipCPU | So your software might ask for address 0x04000000, and the MMU might look up your program, your program's ID, and map that | 13:07 |
| ZipCPU | address to another physical address, such as 0x0008000. | 13:07 |
| kaaliakahn | that is virtual memory !!! Am i correct? | 13:07 |
| ZipCPU | Another programs 0x04000000 address might map to the physical address of 0x09000. (Yes, this is virtual memory.) | 13:08 |
| ZipCPU | The MMU maps virtual to physical memory. | 13:08 |
| kaaliakahn | great. I got it. but why is it necessary to have an MMU to run linux or may be some other application? | 13:08 |
| ZipCPU | Well, let's see ... remember how I told you I built an O/S for the S6SoC? | 13:09 |
| kaaliakahn | yes | 13:09 |
| ZipCPU | To get that to work, I needed to "measure" ahead of time the stack sizes for each process. "Local" memory was not allowed to arbitrarily grow as necessary. | 13:10 |
| ZipCPU | The same is true for "malloc"/free type of memory. I implemented a malloc(), but not a free. | 13:10 |
| ZipCPU | Further, since everything was one address space, one program could read or write anothers memory with no errors. | 13:11 |
| ZipCPU | Some of the bugs I had to deal with while getting the program to work included overwriting the stack of one program, and therefore writing into the kernel's memory structures. | 13:11 |
| kaaliakahn | if you run linux, is n't it like running one program? | 13:11 |
| ZipCPU | On Linux, or a system with a proper MMU, this would've been an error. | 13:12 |
| ZipCPU | Well, I was running multiple ... what would you like to call them? Programs? Tasks? Tasks is probably the more appropriate term. | 13:12 |
| kaaliakahn | what i am saying is that since you have only 1 program, you dont have to worry about memory management | 13:12 |
| ZipCPU | I actually had four separate programs or tasks running on the S6. | 13:13 |
| SMDwrk | But you run something under linux | 13:13 |
| kaaliakahn | what are those 4 tasks | 13:13 |
| SMDwrk | Also linux has different processes running in parallel | 13:13 |
| SMDwrk | So it's not "1 programm" | 13:13 |
| kaaliakahn | got it. Thanks SMDwrk | 13:13 |
| ZipCPU | Likewise with what I was doing. Hold on, let me look up those tasks for you ... | 13:14 |
| kaaliakahn | then perhaps bash prompt or just a shell would be one program? Right SMDwrk? | 13:14 |
| ZipCPU | One task ran the real-time clock, keeping track of time--since I didn't have enough area to do it in hardware. | 13:14 |
| SMDwrk | kaaliakahn: yep | 13:15 |
| ZipCPU | A second task handles a 2-line 2x16 LCD, controlled via SPI port manually. (No SPI hardware control, I bit-banged it ...) | 13:15 |
| ZipCPU | The third task was a "keypad" task that coordinated with the display task to run a minimal menu from a 16-character keypad. | 13:16 |
| ZipCPU | The fourth task was a "doorbell" task. This one played a doorbell audio anytime a button was pressed, but would wait a period of time from one button press to when it played the next. | 13:16 |
| ZipCPU | The application was a security one: when someone presses the doorbell at night, the program was supposed to turn the light on. | 13:16 |
| ZipCPU | The light wasn't supposed to come on during the day, unless switched on. This required knowing time ... etc. | 13:17 |
| kaaliakahn | bravo. Simply excellent. Keep it up. If i could be of any help, I am here | 13:17 |
| ZipCPU | Thank you. | 13:17 |
| kaaliakahn | I have to go now but please message me or put your questions here and someone will get back to you. | 13:17 |
| ZipCPU | The fun of the project has been in the focus on simplicity. I'm not going to declare that I've achieved it, but I've ... tried. | 13:17 |
| ZipCPU | Sure. Let me know if you have any suggestions or questions looking through the documentation. | 13:18 |
| kaaliakahn | sometimes the process is more valuable than the end result. | 13:18 |
| ZipCPU | I also need to go myself--lunch is calling. | 13:18 |
| kaaliakahn | Please remember this life long lesson that i learned the hard way | 13:18 |
| kaaliakahn | cheers | 13:18 |
| ZipCPU | Kaaliakahn: Thank you for your kind words of wisdom. The reality is that if the process wasn't more valuable then end result, I wouldn't still be working on the ZipCPU. Still ... I see the end result of a small, simple, pipelined, 32-bit CPU to be valuable. Whether I can get there, and "what" constitutes getting "there" only time will tell. | 20:29 |
| ZipCPU | I have certainly learned a *lot* along the way. I can tell stories of all of my frustrations, and the things I learned as well. I just don't see myself as qualified to write the book on the topic. Still ... maybe my kids will listen. ;) | 20:30 |
| --- Log closed Wed Jun 01 00:00:32 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!