6 ms·

Writing RTL takes one night but, how long will the verification take? How much will it take to tapeout? Who will pay for it?

oddity 8y ago
As someone living in hardware land, I have a lot of respect for all the effort that goes into those steps of the process and I’m glad you brought it up, but presumably they aren’t that important to the point of a hobby project like this.
- geomark 8y ago
  Another hardware lander here. Did a lot of verification of processors in the past, including one that was Mips-like. Parent comment is correct in its suggestion that verification is a much bigger deal than getting HDL that will compile and pass a few test cases. But for a hobby project, yeah, no need to throw a wet blanket on it.
PhilWright 8y ago
Your only comments on HN seem to be to criticize RISC-V. The posters intention is not to start producing hardware, at no point does his project mention taping it out and manufacturing. Obviously it is just a fun side project to implement the RISC-V core ISA in an FGA. It was then made open-source on GitHub so anyone else interested can look at it. Chill out mate.
- Annatar 8y ago
  "Your only comments on HN seem to be to criticize RISC-V." And in that, he's not alone: have you looked at RISC-V ISA? Compared to MC68000, it's exceptionally retarded, even more so when compared to OpenSPARC. Extremely dumb ISA.
  - waterhouse 8y ago
    If you named anything specific about the RISC-V ISA that you think is retarded, you might contribute something to the conversation.
    - Annatar 8y ago
      Again: have you looked at the assembler code? Are you able to compare MC68000 assembler and RISC-V assembler? Are you able to compare SPARC assembler and RISC-V assembler? Without being able to do that, it's going to be exceptionally difficult for me to contribute any more to the discussion, especially typing on a mobile telephone. That's my contribution for now, I'm pointing out what to compare with. That point was obviously missed. You have to bring something to the table too, instead of just demanding everything be spoon fed and served on a Silver platter to you.
      - waterhouse 8y ago
        I carefully studied the 2.1 and 2.2 versions of the spec. I wrote, in Racket, a miniature interpreter for lists of RISC-V instructions (just symbolic lists, not the byte strings they assemble into), then wrote programs to compute triangular numbers and Fibonacci, and verified they worked. I've built the RISC-V toolchain and compiled a few test C programs and run them in "spike". I don't think I took more than a glance at the "gcc -S" output. I have no familiarity with SPARC or Motorola assembly, but I have decent familiarity with x86-64 assembly, having written what looks like a couple dozen miniature test programs and one medium-sized program, and having tried a few times to write a decent x86-64 assembler. I found the RISC-V spec enjoyable to read, especially with all the rationales; it felt clean, minimal, and well-thought-out. Writing a program in it was probably not much different from writing in x86-64 assembly. The encodings seemed much easier to deal with than x86-64, though as mentioned I didn't go as far as writing an encoder. What kinds of important features are present in SPARC or MC68k but not in RISC-V? Are they absent from x86-64 as well?
        Annatar 8y ago
        Motorola assembler is what is known as orthogonal instruction set. The flow is logical: move.b for byte, move.w for word, move.l for longword, from source to destination, which reflects real life. The assembler reads almost like a high level programming language. The register scheme is intuitive as well, from a0-a7 being the address, to d0-d7 being the data registers. Now, let's do a mental exercise: I'm going to load an effective address relative to the program counter, 32-bits wide, into the 1st address register. Then, I'm going to load an arbitrary value from an arbitrary memory location into the second address register. Do the same in RISC-V; compare intuitiveness. lea MemoryAddress(pc), a0 move.l $00bfe001, a1 rts MemoryAddress: DC.l 0
  - empath75 8y ago
    Calling things ‘retarded’ as an insult is a very juvenile thing to do.
    - Annatar 8y ago
      Retardation, by definition, is something backward, and RISC-V instruction set is backward, since it is empathically not an improvement over what we already have in OpenSPARC or MC68000 in terms of clean design or intuitiveness. Perhaps you rely on the childish and not the engineering use of retardation, whereby I suspect that it's a cultural thing.
craftyguy 8y ago
> Writing RTL takes one night but, how long will the verification take? Obviously more than a night, but hey development is completely open so you can see for yourself. > How much will it take to tapeout? 0 days. It is running on an FPGA. > Who will pay for it? See previous comment. Presumably the author paid for the FPGA, but maybe it was a gift?
- samsoniuk 8y ago
  Almost! For most of time I work only in the simulator (Xilinx ISIM), but luckily I have lots of FPGA boards available at work too!
samsoniuk 8y ago
After two weeks, I hope most critical problems are already solved, as long more complex software is working without problems, thanks to the clear and simple RV32I instruction set! Of course, as observed in the project description, I am working only with FPGAs, which means that is far more faster and easy to simulate with real software and find problems. As long most of complex work is done by the FPGA tool and I have a well comported clock environment, always according to the specifications, the verification is purely logical.

oddity 8y ago

As someone living in hardware land, I have a lot of respect for all the effort that goes into those steps of the process and I’m glad you brought it up, but presumably they aren’t that important to the point of a hobby project like this.

geomark 8y ago
Another hardware lander here. Did a lot of verification of processors in the past, including one that was Mips-like. Parent comment is correct in its suggestion that verification is a much bigger deal than getting HDL that will compile and pass a few test cases. But for a hobby project, yeah, no need to throw a wet blanket on it.

PhilWright 8y ago

Your only comments on HN seem to be to criticize RISC-V. The posters intention is not to start producing hardware, at no point does his project mention taping it out and manufacturing. Obviously it is just a fun side project to implement the RISC-V core ISA in an FGA. It was then made open-source on GitHub so anyone else interested can look at it. Chill out mate.

Annatar 8y ago
"Your only comments on HN seem to be to criticize RISC-V." And in that, he's not alone: have you looked at RISC-V ISA? Compared to MC68000, it's exceptionally retarded, even more so when compared to OpenSPARC. Extremely dumb ISA.
- waterhouse 8y ago
  If you named anything specific about the RISC-V ISA that you think is retarded, you might contribute something to the conversation.
  - Annatar 8y ago
    Again: have you looked at the assembler code? Are you able to compare MC68000 assembler and RISC-V assembler? Are you able to compare SPARC assembler and RISC-V assembler? Without being able to do that, it's going to be exceptionally difficult for me to contribute any more to the discussion, especially typing on a mobile telephone. That's my contribution for now, I'm pointing out what to compare with. That point was obviously missed. You have to bring something to the table too, instead of just demanding everything be spoon fed and served on a Silver platter to you.
    - waterhouse 8y ago
      I carefully studied the 2.1 and 2.2 versions of the spec. I wrote, in Racket, a miniature interpreter for lists of RISC-V instructions (just symbolic lists, not the byte strings they assemble into), then wrote programs to compute triangular numbers and Fibonacci, and verified they worked. I've built the RISC-V toolchain and compiled a few test C programs and run them in "spike". I don't think I took more than a glance at the "gcc -S" output. I have no familiarity with SPARC or Motorola assembly, but I have decent familiarity with x86-64 assembly, having written what looks like a couple dozen miniature test programs and one medium-sized program, and having tried a few times to write a decent x86-64 assembler. I found the RISC-V spec enjoyable to read, especially with all the rationales; it felt clean, minimal, and well-thought-out. Writing a program in it was probably not much different from writing in x86-64 assembly. The encodings seemed much easier to deal with than x86-64, though as mentioned I didn't go as far as writing an encoder. What kinds of important features are present in SPARC or MC68k but not in RISC-V? Are they absent from x86-64 as well?
      - Annatar 8y ago
        Motorola assembler is what is known as orthogonal instruction set. The flow is logical: move.b for byte, move.w for word, move.l for longword, from source to destination, which reflects real life. The assembler reads almost like a high level programming language. The register scheme is intuitive as well, from a0-a7 being the address, to d0-d7 being the data registers. Now, let's do a mental exercise: I'm going to load an effective address relative to the program counter, 32-bits wide, into the 1st address register. Then, I'm going to load an arbitrary value from an arbitrary memory location into the second address register. Do the same in RISC-V; compare intuitiveness. lea MemoryAddress(pc), a0 move.l $00bfe001, a1 rts MemoryAddress: DC.l 0
- empath75 8y ago
  Calling things ‘retarded’ as an insult is a very juvenile thing to do.
  - Annatar 8y ago
    Retardation, by definition, is something backward, and RISC-V instruction set is backward, since it is empathically not an improvement over what we already have in OpenSPARC or MC68000 in terms of clean design or intuitiveness. Perhaps you rely on the childish and not the engineering use of retardation, whereby I suspect that it's a cultural thing.

craftyguy 8y ago

> Writing RTL takes one night but, how long will the verification take? Obviously more than a night, but hey development is completely open so you can see for yourself. > How much will it take to tapeout? 0 days. It is running on an FPGA. > Who will pay for it? See previous comment. Presumably the author paid for the FPGA, but maybe it was a gift?

samsoniuk 8y ago
Almost! For most of time I work only in the simulator (Xilinx ISIM), but luckily I have lots of FPGA boards available at work too!

samsoniuk 8y ago

After two weeks, I hope most critical problems are already solved, as long more complex software is working without problems, thanks to the clear and simple RV32I instruction set! Of course, as observed in the project description, I am working only with FPGAs, which means that is far more faster and easy to simulate with real software and find problems. As long most of complex work is done by the FPGA tool and I have a well comported clock environment, always according to the specifications, the verification is purely logical.