7 ms·

My thoughts exactly. When I saw "Perhaps the Verilog language is not so good, because some nice standard language featuers (forever-loop etc.) are missing in th

by jff 12y ago

My thoughts exactly. When I saw "Perhaps the Verilog language is not so good, because some nice standard language featuers (forever-loop etc.) are missing in the Xilinx-Tools.", I had flashbacks to VHDL class, students writing loops and then wondering why they couldn't synthesize the code. You have to get yourself into a hardware mindset, thinking about clocks and state machines and enable lines rather than infinite loops.

AceJohnny2 12y ago
Yeah, it looks like this guy needs to learn more Verilog before he can make progress on the CPU implementation. It reminds of teaching some VHDL in a hackerspace a few years ago (I had learned it in college some years previously), and this software guy was constantly trying to write functions and loops, and was having trouble with the concept that all signals were propagated concurrently rather than sequentially! Sure, it looks like code (in fact, VHDL's syntax is purposefully similar to ADA), but it sure isn't code.
- skylan_q 12y ago
  Sure, it looks like code (in fact, VHDL's syntax is purposefully similar to ADA), but it sure isn't code. Computer science grad here. I had to keep reminding myself about the HDL part of VHDL. It's not algorithmic description like programming is, but hardware description.
- spacemanmatt 12y ago
  Would it be fair to describe it as concurrently executed code?
  - AceJohnny2 12y ago
    hah, that's only the tip of the iceberg... From memory: - HDL code doesn't have variables the way programming code does. Sure, you can store state in latches (and other more roundabout ways), but a good design tries to avoid this. - You can have "functions" that take parameters, but what you're really doing is instantiating blocks of hardware according to said parameters. - Instead of variables to functions, what you really care about is signals as input and output to hardware blocks. (and ultimately at the final hardware implementation, propagation time and power of said signals. Especially the clock. OMG the clock...) Honestly, I found VHDL made complete sense from approaching it after drawing digital circuit diagrams, as the description code mapped pretty clearly to that. Approaching it from an "imperative programming" background makes little sense, and saying it's "concurrent programming" just ends up confusing the issue more, IMHO.
    - ioseph 12y ago
      Absolutely agree with learning digital circuit design first. Before writing a single line of HDL, you should know exactly what you want to be synthesized. Unfortunately all to many courses approach like learning a new programming language. To me this is like teaching CAD before teaching how to draw a rectangle.
  - ohyes 12y ago
    It's more like wiring together a series of tubes. The signal has to propagate from one end of the tubes to the other in a single clock cycle. Note that the tubes can go backwards, so you can feed the output of the tube into the next input of itself. Hardware programming like this is actually extremely fun, but for some reason the widely available languages for doing it suck. And make what is going on in the hardware opaque and difficult to understand for any non trivial applications. (We're talking 100000s of lines of code to do anything nontrivial).
  - MootWoop 12y ago
    I think you could. Contrary to most comments on this page, I do think that you should be able to write high-level code with "if" and "while" and have the compiler generate the hardware for you. Actually, that's what we (Synflow) are doing with our language. So you don't have to spend so much time learning Verilog/VHDL and typing all those Finite State Machines and scheduling next state processes and so on. Take a look at our website www.synflow.com and let us know what you think!
- austinz 12y ago
  It's funny, because in some cases you can write HDL code that looks like a loop - but in this context a loop instantiates multiple instances of some piece of logic.
  - AceJohnny2 12y ago
    Exactly. And this kind of distinction was what we were having trouble conveying to said software guy (I say this as a software guy myself), and I think the author of the LISP CPU is having the same problem.
    - derefr 12y ago
      I think I'd explain that particular bit by simply saying that there was no run-time looping construct, only a compile-time looping macro to generate runtime code. Most software people would get that, I think.
- read 12y ago
  this guy needs to learn more Verilog That's not a bad thing. Maybe this is why a Lisp processor doesn't exist. Not only do you have to know Lisp well, which only a minority of programmers do, but you also need to want to know hardware. Which is something software people don't want to do. This guy already has a leg up. For some strange reason I can't explain it's easier to imagine a software guy building hardware than a hardware guy writing a Lisp.
  - jff 12y ago
    That seems odd when you consider that a Lisp can be implemented in, what, a couple hundred lines of C? All the guys who can design a processor know how to program, and it's not like Lisp is totally magical. Now, most people who do primarily hardware work probably aren't that interested in Lisp, because there's not really much Lisp focus out there. I'm a computer engineer, I know how to write HDL and lay silicon, I like Lisp... actually it would be a pretty fun project to do in an FPGA.
    - read 12y ago
      They know how to program. Do they know what to program?
- derefr 12y ago
  > this software guy was constantly trying to write functions and loops, and was having trouble with the concept that all signals were propagated concurrently rather than sequentially! Sounds like he hadn't written much software in a language with an actor-model. It's not nearly as hard a jump to VHDL if you've ever debugged an Erlang supervision tree, or a miscommunicating set of SOA web services.
- romaniv 12y ago
  If you teach Verilog without explaining why it has loops and what they do (and don't do), you don't teach it correctly. Behavioral descriptions are very, very similar to programming, and a lot of programming concepts and skills (e.g. modularization) translate very well to HDLs. The only thing in HDLs I remember that is totally alien to programmers is propagation delays. Well, even that is somewhat similar to multi-threading issues.

by jff 12y ago

AceJohnny2 12y ago

Yeah, it looks like this guy needs to learn more Verilog before he can make progress on the CPU implementation. It reminds of teaching some VHDL in a hackerspace a few years ago (I had learned it in college some years previously), and this software guy was constantly trying to write functions and loops, and was having trouble with the concept that all signals were propagated concurrently rather than sequentially! Sure, it looks like code (in fact, VHDL's syntax is purposefully similar to ADA), but it sure isn't code.

skylan_q 12y ago
Sure, it looks like code (in fact, VHDL's syntax is purposefully similar to ADA), but it sure isn't code. Computer science grad here. I had to keep reminding myself about the HDL part of VHDL. It's not algorithmic description like programming is, but hardware description.
spacemanmatt 12y ago
Would it be fair to describe it as concurrently executed code?
- AceJohnny2 12y ago
  hah, that's only the tip of the iceberg... From memory: - HDL code doesn't have variables the way programming code does. Sure, you can store state in latches (and other more roundabout ways), but a good design tries to avoid this. - You can have "functions" that take parameters, but what you're really doing is instantiating blocks of hardware according to said parameters. - Instead of variables to functions, what you really care about is signals as input and output to hardware blocks. (and ultimately at the final hardware implementation, propagation time and power of said signals. Especially the clock. OMG the clock...) Honestly, I found VHDL made complete sense from approaching it after drawing digital circuit diagrams, as the description code mapped pretty clearly to that. Approaching it from an "imperative programming" background makes little sense, and saying it's "concurrent programming" just ends up confusing the issue more, IMHO.
  - ioseph 12y ago
    Absolutely agree with learning digital circuit design first. Before writing a single line of HDL, you should know exactly what you want to be synthesized. Unfortunately all to many courses approach like learning a new programming language. To me this is like teaching CAD before teaching how to draw a rectangle.
- ohyes 12y ago
  It's more like wiring together a series of tubes. The signal has to propagate from one end of the tubes to the other in a single clock cycle. Note that the tubes can go backwards, so you can feed the output of the tube into the next input of itself. Hardware programming like this is actually extremely fun, but for some reason the widely available languages for doing it suck. And make what is going on in the hardware opaque and difficult to understand for any non trivial applications. (We're talking 100000s of lines of code to do anything nontrivial).
- MootWoop 12y ago
  I think you could. Contrary to most comments on this page, I do think that you should be able to write high-level code with "if" and "while" and have the compiler generate the hardware for you. Actually, that's what we (Synflow) are doing with our language. So you don't have to spend so much time learning Verilog/VHDL and typing all those Finite State Machines and scheduling next state processes and so on. Take a look at our website www.synflow.com and let us know what you think!
austinz 12y ago
It's funny, because in some cases you can write HDL code that looks like a loop - but in this context a loop instantiates multiple instances of some piece of logic.
- AceJohnny2 12y ago
  Exactly. And this kind of distinction was what we were having trouble conveying to said software guy (I say this as a software guy myself), and I think the author of the LISP CPU is having the same problem.
  - derefr 12y ago
    I think I'd explain that particular bit by simply saying that there was no run-time looping construct, only a compile-time looping macro to generate runtime code. Most software people would get that, I think.
read 12y ago
this guy needs to learn more Verilog That's not a bad thing. Maybe this is why a Lisp processor doesn't exist. Not only do you have to know Lisp well, which only a minority of programmers do, but you also need to want to know hardware. Which is something software people don't want to do. This guy already has a leg up. For some strange reason I can't explain it's easier to imagine a software guy building hardware than a hardware guy writing a Lisp.
- jff 12y ago
  That seems odd when you consider that a Lisp can be implemented in, what, a couple hundred lines of C? All the guys who can design a processor know how to program, and it's not like Lisp is totally magical. Now, most people who do primarily hardware work probably aren't that interested in Lisp, because there's not really much Lisp focus out there. I'm a computer engineer, I know how to write HDL and lay silicon, I like Lisp... actually it would be a pretty fun project to do in an FPGA.
  - read 12y ago
    They know how to program. Do they know what to program?
derefr 12y ago
> this software guy was constantly trying to write functions and loops, and was having trouble with the concept that all signals were propagated concurrently rather than sequentially! Sounds like he hadn't written much software in a language with an actor-model. It's not nearly as hard a jump to VHDL if you've ever debugged an Erlang supervision tree, or a miscommunicating set of SOA web services.
romaniv 12y ago
If you teach Verilog without explaining why it has loops and what they do (and don't do), you don't teach it correctly. Behavioral descriptions are very, very similar to programming, and a lot of programming concepts and skills (e.g. modularization) translate very well to HDLs. The only thing in HDLs I remember that is totally alien to programmers is propagation delays. Well, even that is somewhat similar to multi-threading issues.