Rabbit does not have as many features as Tortoise, but don't be put off by the version number. Many programs and projects are fully usable despite low version numbers - while others use high version numbers for their initial releases.
I find Rabbit more reliable than Tortoise at getting the overlay icons correct, but maybe that's just Nautilus being more consistent and accurate than Windows Explorer. But there is no doubt that Tortoise has lots more useful subversion features.
I also do much of my subversion stuff from the command line, both in Windows and Linux - and also some from within programs with svn support (such as Eclipse). But Rabbit and Tortoise are very good for quickly viewing the state of files, as well as getting logs and differences.
Mmh, I'm more and more getting into the chisel thing. I like it and maybe this gives me (and others, like my students) a productivity boost.
My thoughts about risk: yes, there is a risk with using a new not yet established language. However, three arguments against being afraid: (1) it is the design and not the description that counts. If you need to drop a tool/language, rewriting your design in a new language is not that much work. (2) it uses Verilog as intermediate language. So the synthesize heavy lifting is done by the well established tools in a well established language. (3) it is open source. You can always contribute patches to the project to fix issues. If they are ignored you can still fork for your project to survive, although OS project forking is a bad idea.
"Mmh, I'm more and more getting into the chisel thing. I like it and maybe this gives me (and others, like my students) a productivity boost."
Martin,
I'd rather universities teach students how to get more productivity out of the existing, standard, tool-supported HDLs. The status quo, perhaps due to the required simplicity of class projects, is typically an HDL description written at barely above the netlist level anyway. Very little attention is typically paid to SW engineering principles that become critical (and extr emely productive) on larger, more complex projects. If these principles and techniques are not taught to HW students, any productivity increases obser ved while merely changing languages will be marginal at best. At some point , the level of abstraction has to get beyond the current 'This is a registe r; these are some gates.' approach to HDL-based design, or it does not matt er what language you use.
"My thoughts about risk: yes, there is a risk with using a new not yet esta blished language. However, three arguments against being afraid: (1) it is the design and not the description that counts. If you need to drop a tool/ language, rewriting your design in a new language is not that much work."
Does that "not much work" include re-writing your development processes and procedures, coding and review standards, development and verification plan s, not to mention test benches? And is this true for most designs, or just the typical class project level designs?
"(2) it uses Verilog as intermediate language. So the synthesize heavy lift ing is done by the well established tools in a well established language."
So when you get a synthesis error/warning, it refers you to the machine-gen erated, intermediate language code, which is cross-referenced to the origin al source code how?
MyHDL takes this same approach (it actually produces both VHDL and Verilog to support synthesis and other tools). However, the MyHDL source is "elabor ated" before the conversion to the supported HDLs, which means that if you have a parameterizable source module (that could have been kept parameteriz ed in VHDL), you get a separate version of the HDL for every unique paramet erization, thus further stretching the already tenuous connection between t he source that is written, reviewed and maintained, and the HDL your synthe sis tool is warning you about.
"(3) it is open source. You can always contribute patches to the project to fix issues. If they are ignored you can still fork for your project to sur vive, although OS project forking is a bad idea. Cheers, Martin"
The tool vendors are unlikely to support an HDL that has no controlled stan dard; it's too fluid a target to hit. Until it is controlled and tool-suppo rted, its real-world productivity gains are practically zero, if not negati ve.
this gives me (and others, like my students) a productivity boost."
existing, standard, tool-supported HDLs. The status quo, perhaps due to the required simplicity of class projects, is typically an HDL description written at barely above the netlist level anyway. Very little attention is typically paid to SW engineering principles that become critical (and extremely productive) on larger, more complex projects. If these principles and techniques are not taught to HW students, any productivity increases observed while merely changing languages will be marginal at best. At some point, the level of abstraction has to get beyond the current 'This is a register; these are some gates.' approach to HDL-based design, or it does not matter what language you use.
established language. However, three arguments against being afraid: (1) it is the design and not the description that counts. If you need to drop a tool/language, rewriting your design in a new language is not that much work."
procedures, coding and review standards, development and verification plans, not to mention test benches? And is this true for most designs, or just the typical class project level designs?
is done by the well established tools in a well established language."
machine-generated, intermediate language code, which is cross-referenced to the original source code how?
support synthesis and other tools). However, the MyHDL source is "elaborated" before the conversion to the supported HDLs, which means that if you have a parameterizable source module (that could have been kept parameterized in VHDL), you get a separate version of the HDL for every unique parameterization, thus further stretching the already tenuous connection between the source that is written, reviewed and maintained, and the HDL your synthesis tool is warning you about.
fix issues. If they are ignored you can still fork for your project to survive, although OS project forking is a bad idea. Cheers, Martin"
standard; it's too fluid a target to hit. Until it is controlled and tool-supported, its real-world productivity gains are practically zero, if not negative.
No way, if they learn how to design and architect complex digital systems and are able to implement them successfully, regardless of the tool, I think the students will be prepared (this depends a lot on the definition of "successfully").
Of course the students will have a learning curve changing HDLs. But at this point they should have a good idea what the tools provide and do not provide. The greater risk is they will be frustrated not having the power and will quit :)
support synthesis and other tools). However, the MyHDL source is "elaborated" before the conversion to the supported HDLs, which means that if you have a parameterizable source module (that could have been kept parameterized in VHDL), you get a separate version of the HDL for every unique parameterization, thus further stretching the already tenuous connection between the source that is written, reviewed and maintained, and the HDL your synthesis tool is warning you about.
fix issues. If they are ignored you can still fork for your project to survive, although OS project forking is a bad idea. Cheers, Martin"
standard; it's too fluid a target to hit. Until it is controlled and tool-supported, its real-world productivity gains are practically zero, if not negative.
I have not found this to be an issue, mainly because I have no synthesis errors after simulating and cosimulating, the design works as expected. Yes, if for some reason you had many synthesis error tracing back would be more work than tracing to the Verilog/ VHDL source but I think it is minimal compared to the simulation and verification gains.
"I have not found this to be an issue, mainly because I have no synthesis e rrors after simulating and cosimulating, the design works as expected. Yes, if for some reason you had many synthesis error tracing back would be more work than tracing to the Verilog/ VHDL source but I think it is minimal co mpared to the simulation and verification gains. Regards, Chris"
Chris,
I get very few synthesis "errors" during synthesis, and none by the time I' m finished.
But I get lots of synthesis "warnings" and "notes" about what is getting op timized out, what is being retimed, replicated, etc., even after a design s imulates correctly.
Simulating correctly and resulting in reliable hardware are not synonymous.
If you have no synthesis notes/warnings about signals/registers getting opt imized away, you are likely designing at an unproductively low level of abs traction.
When you simulate, are you simulating in the source language, or the interm ediate RTL? If at the intermediate RTL level, how are you tracing simulatio n errors back to your source? If at the source level, how are you simulatin g post-synthesis/P&R (gate level sims) with the same testbench?
optimized out, what is being retimed, replicated, etc., even after a design simulates correctly.
Impossible not to get millions of notes and warnings, the behavior of my final circuits match the behavior of my descriptions, they work in the field no complaints thus far.
I agree but two ASICs and a dozen successful FPGAs says what needs to be checked is checked and attention where attention is required.
optimized away,
As stated above, with all FPGA tools it is virtually impossible not to get numerous warnings and errors. As long as the tools don't change the behavior they can optimize away.
I doubt that!
intermediate RTL? If at the intermediate RTL level, how are you tracing simulation errors back to your source? If at the source level, how are you simulating post-synthesis/P&R (gate level sims) with the same testbench?
I am simulating the source and cosimulating (meaning using my high-level HDL with the converted and/or synthesized HDL) and using the high-level verification environment to verify the converted matches the source. Optionally, will verify the post P&R (more so with the ASIC flow less so with FPGA). I am also able to leverage the same verification code in the lab, the code that tested the models also tests the logic in the lab.
Do you ignore synthesis notes and warnings, or do you cross-check at least some of them?
There are precious few efficient ways to confirm "completeness" of the desi gn verification effort.
I cross-check my synthesis warnings as a secondary confirmation that someth ing is not missed either in the design or in the verification. I can usuall y tell from the warning, and knowledge of the design, whether it is a poten tial problem or is acceptable/expected. I do not modify the design to elimi nate acceptable/expected warnings (that would require designing at too low a level of abstraction). It still takes a lot of time, but it has been very effective, not only as a secondary confirmation of verification, but also as an indication of where/not to improve performance or utilization to meet requirements.
If I used an alternative HDL as source, then I'd have to trace the warnings I could not immediately resolve back through the intermediate code to the source. That takes more time, and from what I have seen, would not be offse t by any improvmement in productivity provided by the alternative language.
If I used verilog, I might have a different opinion.
However, where other languages, perhaps including these alternative HDLs, m ay be more helpful is in the verification of the HDL design, regardless of the HDL used (traditional or alternative).
No I don't ignore them, they are reviewed and certain ones are interrogated if deemed important. And determining if they are important is decided by the design engineer, same as you, they are aware of the design and "no problemo" referring back to the original source, if needed.
verification effort.
is not missed either in the design or in the verification. I can usually tell from the warning, and knowledge of the design, whether it is a potential problem or is acceptable/expected. I do not modify the design to eliminate acceptable/expected warnings (that would require designing at too low a level of abstraction). It still takes a lot of time, but it has been very effective, not only as a secondary confirmation of verification, but also as an indication of where/not to improve performance or utilization to meet requirements.
could not immediately resolve back through the intermediate code to the source. That takes more time, and from what I have seen, would not be offset by any improvmement in productivity provided by the alternative language.
be more helpful is in the verification of the HDL design, regardless of the HDL used (traditional or alternative).
In this case the alternative HDL used is MyHDL, and MyHDL
-in my experience- does not mangle the source enough to prohibit tracing back. As you indicated, it does have an "elaboration" phase but this has not been an issue (tracing back the generated VHDL or Verilog).
I agree, the alternative HDL (because they are typically based on as general purpose high-level language) are ideal for modeling and verification. The V*s will always lag the other languages for general features.
On Saturday, 29 December 2012 00:06:20 UTC, Martin Schoeberl wrote (with s lightly less compacted blank-lines than this):
I haven't seen mention of PSHDL (pshdl.org) which I have recently come acro ss via a talk at CCC (German conference), is this worthy of consideration a lso? Seems it is/can be converted into one of (/both?) the V* languages for end-use and is aiming to make it easier to learn for beginners (like mysel f).
I'm a Berkeley PhD student who has worked extensively with Chisel both in classes and research. I love it, though I did not have much experience with anything else before starting on it. A common description for Chisel I use is "hardware at the word level". It allows for n-dimensional arrays of hardware (wires, gates, modules, whatever). We call it a hardware construction language because it can generate an array of different architectures by changing the input parameters. Another benefit is the cycle-accurate C++ tester, which allows for fast design verification. You do need to learn Chisel and Scala, though they have many similarities. Learning Verilog isn't necessary unless you want to post-process the output for some reason. So maybe it involves only learning 1.5 new languages! There is no VHDL support, nor talk of including it.
To attempt remaining unbiased, I'd also like to mention MyHDL, which is an HDL built on Python (a language people are generally more familiar with). If your fear is learning new languages, this might be a good alternative. I know nothing about it save its existence.
I have use Chisel for 2 projects with some complexity and a lot of clock do main.
The first is a real time simulator that is able to simulate in real time el ectrical network. Project has some AD/DA, hundreds of processing core, AXI master/slave, DDR3, multiple clock domain. The second was a Mandelbrot accelerator with 8 pipelined cores that fill DD R3 frame buffer and have a UART control link.
Good part of Chisel : - increase productivity - Genericity unlocked - Scala possibilities - Check logic loop and don't allow latch
Bad part of chisel : - Multi clock support is really not well designed. Usable but very bad - Don't handle conditional blocks on combinatorial signals correctly - Don't allow to do ranged assignments on signals: myBits(3 downto 2)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.