So did the American legal system. So did most civilizations before the 19th century. Honestly, it's rather knee-jerk to go "slavery means nothing was good about that society!". There's a huge degree of gray area between society with slaves, society without slaves, and Feudal society where 95%+ of the population were living in a slave-like environment.
Comparatively, the citizens (i.e. non-slaves) that made up the majority of Persian, Roman, English and yes, American society were treated equally under law and had at least some degree of basic Constitutional rights that even the Emperor/Caesar/King/Federal Government couldn't overstep.
Historically, the two have had high correlation. See Persians, Romans, British, American, etc.
While they weren't perfectly free nations, they each had quite progressive legal systems that provided relatively good degrees of equality and freedom to its citizens compared to other major powers of the world at the time.
ARM is actually well ahead of Atom in this one. The Cortex A8 and A9 can be bought with an SIMD FPU unit that offers (relatively) flexible memory access instructions that I think only the latest Core resembles.
There's also the GPU peripheral IP available through ARM. Their SDK supports it.
I agree that Castro Cuba was actually an implemented communist economy (leaning more towards socialist though due to the central concentration of power sometimes deviating from the desires and needs of the population). I don't think that qualifies as "working". What's the average quality of life there? How is the country doing economically in the global scheme of things?
Last I checked, it was a pretty poor country whose industry consisted of tourism, sugar, tobacco and raw materials. Its education system is a sham, its medical facilities outdated. Hell Cuba imports 80% of their food because their agriculture system is so poor.
A lot of that may have to do with the U.S. embargo but it's pretty plain to see Cuba is anything but a self-sustaining working communal system.
Since when has "propaganda" meant "sole news source enforced by the government"? Last I checked, it simply meant an unfair advertisement in which data was either excluded, made up, or presented in such a form as to support one point of view.
Yes, the U.S. is miles ahead of the Chinese media in that there is still a free (for purchase) press. That doesn't take away from the fact that they all seem to like to report on the negative actions of the Chinese government (and there are many). Now, this may very well be just a side-effect of the fact that people in the U.S. have a generally negative feeling towards the Chinese government and that reporting such things that reinforces this view sells news. That doesn't make it any less lopsided.
I've always viewed the press as a 4th branch of government. Its purpose should not be to report what brings in money; it should be reporting as much of the facts as it can get its hands on. In that, our current media has failed.
The U.S. notion of freedom doesn't even apply to the U.S. See Patriot Act and the recent changes to FISA. See the DMCA. See the Bush (and now Obama) administration.
While I truly believe in the ideals of democracy and civil rights, there have always been times when practicality has been opposed to it. Of course, an authoritarian government cannot sustain itself (see USSR, China pre-capitalist expansion, Cuba, etc.) economically, so eventually the government will have to let the reigns loose if it wants to preserve the country in the global scheme of things.
Of course, after about 500 glasses of C++, you're pretty much shit faced and can't even pour straight let alone remember to throw the beer can away immediately. This is when having a beer-can Roomba would come in handy.
Because it's not. It's not a list of instructions. It doesn't describe what to do. It simply describes structure. A program, by its most basic definition, is a set of instructions. It's a procedure of what to do:
add this to this. copy this to that. turn these bits to 0's.
Ok, I'll bite - what does VHDL give you control over that Verilog doesn't?
Most of it has to do with typing. There really isn't much in Verilog. An anecdotal problem is getting:
data = array[addr+offset] to synthesize with "addr" being the bitsize you want. Even if offset and addr are both 16 bits, there's a good chance the integer result will be 32 bits and you'll find a lot of registers used for the address bus.
VHDL strong types it. It doesn't allow this type of ambiguity. Granted that's not a limitation of Verilog. You can be anal and not use the shorthand for addition inside an array address. But most would:)
Agreed. Although for anything beyond directed tests, most have moved to either C models with VPI (or PLI) or straight up SystemVerilog by now. The behavioral and procedural aspects of vanilla Verilog and VHDL are largely outdated.
This is the biggest thing that people have to overcome. Don't worry about it:) The thing you have to realize is that HDL is simply a "hacked together" solution that has never been perfected. Synthesis tools aren't compiling like a programming language compiler, they're guessing. There is no deterministic solution (at least within computable time) for the synthesis process. It has to take shortcuts and fall on non-optimal solutions and (due to the incompleteness of Verilog or VHDL as a hardware description language) sometimes purposely translate circuits that don't have the same functionality as the actual code.
Take:
always @(posedge clk, negedge reset)
for instance. The language is describing that events only happen at the edge of the clk or the edge of reset. But among hardware designers, this syntax has become "tribal knowledge". When synthesis sees this syntax and this exact syntax, it creates an edge sensitive flip-flop with an asynchronous reset. The reset is level-sensitive, not edge sensitive.
People who aren't careful will have their circuit simulate one way (because the simulator obeys the description of the language) but synthesize into gates that behave differently.
Why is such a glaring imperfection allows? Simply put, synthesis algorithms are good at recognizing and creating synchronous circuits from a language description. They're altogether rather poor at recognizing and creating asynchronous circuits. Because async resets are so common, this special provision was put inside all synthesis tools to recognize that construct. But try describing a level-sensitive latch, a delay circuit, an asynchronous feedback circuit, etc. The tool will not handle it very well.
Those things are usually designed by hand.
I would strongly recommend "HDL Chip Design" by Douglas Smith. It's out of print, still sells for $200+ and is about the best book on chip design you'll ever have.
There's some overlap. Stuff like algorithms may be used in both arenas, but the goal of HDL is to make hardware, not programs."
Sounds pretty straightforward to me. "HDL to design hardware is not a programming language, the HDL has some overlapping features that allow you to make programs".
So let's add inability to read and comprehend a statement to your menagerie of tendencies. Don't talk about things you know nothing of just to try to boost your own ego and sound smart. You end up sounding like an idiot to anyone remotely familiar with the field.
25 Years of hardware and software engineering experience.
Who's never touched digital design from my guess. Look, code monkey, you're wrong. I've given you examples of how synthesizable Verilog does not behave like a programming language. You didn't get it. You don't want to get it. You probably saw "hey! there's an if statement! it's a program!"
Kiddie scripting for 25 years means 1. you're out of date and 2. you know nothing about hardware.
If you can't figure out how that's not a program (and my guess is you can't), then you're a lost cause. I'll give you a hint: it's not a program. The fact you don't understand this tells me you have absolutely no understanding of how hardware logic works and moreover are willfully ignorant and unwilling to learn.
Hardware designers give a shit. Because when designing hardware using Verilog, you don't approach it like it's a programming language. Because the programming parts of it don't work when the synthesis tool tries to map it to gates. Hence, Verilog, when designing hardware, is not programming.
An instructor is good but honestly, I've learned more from the compiler than I have from my instructors. That's why I said it's good for an introductory language. After you've learned VHDL, picking up Verilog is easy because you're already aware of all the gotcha's even if your instructor forgot them.
And frankly, for most undergrad students, if they can be sloppy and get it to work (and then go drinking), they will. No matter how much the instructor emphasizes "this may or may not work, do it the other way and it's guaranteed to work", the students won't listen. It's great to have the compiler put a stop to that and actually force them to learn the design concepts.
As for time spent, I'll use an anecdote. For my advanced digital design course as an undergrad, we designed a 32-bit MIPS processor. I did it in Verilog and put it on an FPGA. Our school didn't spend money on top-of-the-line FPGA's so we didn't have fancy features like ChipScope or JTAG debugging. Instead we had to use logic analyzers (running embedded windows and crashing a lot) and spare pins on the FPGA (there were only 12 to spare) as a test mux.
We spent weeks sleeping in the lab debugging that thing. Couldn't figure out why bits 0-8 (or so we thought) of the instruction register didn't look right even though it was executing that instruction. Turns out that because we added an integer count (in the RTL) as an offset to the address of the counter to sequence through the testmux, the address became a 32-bit value instead of the 16 we specified. And because we didn't specify which bits were to be assigned to which of the testmux select lines, synthesis just randomly did it.
That was one of many many many things that would've taken 3 seconds to correct when a VHDL compiler told you to "stop". Instead it took 14 hours. I almost destroyed that thing out of frustration.
Verilog is very much compiled. Try writing a verilog module with a faulty assignment at the end and see if it'll run through even the simulation tool. It won't.
Some of the more popular simulators (VCS, Modelsim) actually create binaries out of the Verilog, associated libraries and invokes GCC for the C-models.
To ring my point home, take the following Verilog example:
always @(posedge clk, negedge areset_n) begin
if(areset == 1'b0) begin
data = preset;
end else begin
if(preset == 1'b1) begin
data = preset;
end else begin
data = data + 1;
end
if((data + 1) == tcnt_val) begin
tcnt = 1'b1;
end else begin
tcnt = 1'b0;
end
end
end
assign dout = en & data; endmodule
1. What is the subtle difference between how this will behave as Verilog (in a simulator) and the real circuit when areset_n is 0 from time 0? What would be a possible solution to this? 2. What are the potential problems with setting "data" to "preset" under the condition "areset_n == 1'b0"? 3. What will "data" be when "tcnt" is 1'b1? 4. Is there anything bad about assigning dout to (en & data)? What would be a reason to do that? What would be a reason to do that assignment inside the "always" block?
Lastly, if this is a program. Translate it into equivalently functional psuedo-assembly.
Except the Verilog you use for actual hardware description involves none of that. When hardware designers say "Verilog" we mean "Verilog for synthesis". Verilog allows you a programming environment that you can do all of the fancy procedural things. But when you use it to describe hardware, you're limited to a fairly small subset of the language that is anything but programming.
Nonsense. Teaching the tool is the job of a vocational program. The theory of HDL will long out-last any particular errors or syntax that come about.
Except in this case the tool is intricately related to the "theory of HDL". This isn't some "sorry, you used \r\n instead of \n" issue. VHDL compile errors are real design issues. Basic issues that every designer needs to understand.
Example:
integer count; bit [8:0] bus;
always @(posedge clk, negedge reset) begin
if(reset == 0) begin
count = 0;
end else begin
count = count + 1;
end end
assign bus = count;
This is all legal in Verilog. Its equivalent VHDL would throw a huge fit. Does the student who uses Verilog for this understand how it will be translated? Design Compiler will do the following things "behind the student's back" with a list of warnings inside the log that most undergrads won't bother looking at:
1. It will assign "bus" to the first 8 bits of count. This may or may not be the desired behavior. 2. It will treat count as a signed integer, it's probable that it is meant to be an unsigned counter. 3. It will optimize by encoding the counter in something other than BCD. The ambiguities of how the bits of "count" are assigned to "bus" with the encoding scheme of choice are non-obvious.
VHDL makes you explicitly describe all of these things. It may seem a "pain in the ass" but these concepts are ones that any designer should understand *before* they commit something to silicon (or SRAM in the case of Xilinx).
After you understand all of this, moving to Verilog will save you time (as long as you're careful) by letting the compiler do more of the manual translations for you.
I know you're trying to sound smart here. But it really doesn't take away from my point. Past point x (fill in whatever number you think is beyond the point of noticeability), you can run at any "stellar speed" you want and it wouldn't make a difference. Designing for slow systems with that in mind leads to not utilizing high-end systems.
I don't think there's a single synthesis tool out there that will let you synthesize a design without at least a clock. Other timing constraints aside, without a clock specification, there's ambiguities as to how to synthesize it to synchronous logic.
Slashdot Mirror
So did the American legal system. So did most civilizations before the 19th century. Honestly, it's rather knee-jerk to go "slavery means nothing was good about that society!". There's a huge degree of gray area between society with slaves, society without slaves, and Feudal society where 95%+ of the population were living in a slave-like environment.
Comparatively, the citizens (i.e. non-slaves) that made up the majority of Persian, Roman, English and yes, American society were treated equally under law and had at least some degree of basic Constitutional rights that even the Emperor/Caesar/King/Federal Government couldn't overstep.
Historically, the two have had high correlation. See Persians, Romans, British, American, etc.
While they weren't perfectly free nations, they each had quite progressive legal systems that provided relatively good degrees of equality and freedom to its citizens compared to other major powers of the world at the time.
ARM is actually well ahead of Atom in this one. The Cortex A8 and A9 can be bought with an SIMD FPU unit that offers (relatively) flexible memory access instructions that I think only the latest Core resembles.
There's also the GPU peripheral IP available through ARM. Their SDK supports it.
I agree that Castro Cuba was actually an implemented communist economy (leaning more towards socialist though due to the central concentration of power sometimes deviating from the desires and needs of the population). I don't think that qualifies as "working". What's the average quality of life there? How is the country doing economically in the global scheme of things?
Last I checked, it was a pretty poor country whose industry consisted of tourism, sugar, tobacco and raw materials. Its education system is a sham, its medical facilities outdated. Hell Cuba imports 80% of their food because their agriculture system is so poor.
A lot of that may have to do with the U.S. embargo but it's pretty plain to see Cuba is anything but a self-sustaining working communal system.
Since when has "propaganda" meant "sole news source enforced by the government"? Last I checked, it simply meant an unfair advertisement in which data was either excluded, made up, or presented in such a form as to support one point of view.
Yes, the U.S. is miles ahead of the Chinese media in that there is still a free (for purchase) press. That doesn't take away from the fact that they all seem to like to report on the negative actions of the Chinese government (and there are many). Now, this may very well be just a side-effect of the fact that people in the U.S. have a generally negative feeling towards the Chinese government and that reporting such things that reinforces this view sells news. That doesn't make it any less lopsided.
I've always viewed the press as a 4th branch of government. Its purpose should not be to report what brings in money; it should be reporting as much of the facts as it can get its hands on. In that, our current media has failed.
The U.S. notion of freedom doesn't even apply to the U.S. See Patriot Act and the recent changes to FISA. See the DMCA. See the Bush (and now Obama) administration.
While I truly believe in the ideals of democracy and civil rights, there have always been times when practicality has been opposed to it. Of course, an authoritarian government cannot sustain itself (see USSR, China pre-capitalist expansion, Cuba, etc.) economically, so eventually the government will have to let the reigns loose if it wants to preserve the country in the global scheme of things.
There's nothing in the article about Paris Hilton.
Of course, after about 500 glasses of C++, you're pretty much shit faced and can't even pour straight let alone remember to throw the beer can away immediately. This is when having a beer-can Roomba would come in handy.
You could calculate e^(-x) with sin and cos...
You can even do it with bit-shifting using a CORDIC algorithm.
Because it's not. It's not a list of instructions. It doesn't describe what to do. It simply describes structure. A program, by its most basic definition, is a set of instructions. It's a procedure of what to do:
add this to this.
copy this to that.
turn these bits to 0's.
etc. SPICE doesn't do this.
Ok, I'll bite - what does VHDL give you control over that Verilog doesn't?
Most of it has to do with typing. There really isn't much in Verilog. An anecdotal problem is getting:
data = array[addr+offset] to synthesize with "addr" being the bitsize you want. Even if offset and addr are both 16 bits, there's a good chance the integer result will be 32 bits and you'll find a lot of registers used for the address bus.
VHDL strong types it. It doesn't allow this type of ambiguity. Granted that's not a limitation of Verilog. You can be anal and not use the shorthand for addition inside an array address. But most would :)
Agreed. Although for anything beyond directed tests, most have moved to either C models with VPI (or PLI) or straight up SystemVerilog by now. The behavioral and procedural aspects of vanilla Verilog and VHDL are largely outdated.
Simulation was fine. RTL simulation produces the code behavior exactly.
This is the biggest thing that people have to overcome. Don't worry about it :) The thing you have to realize is that HDL is simply a "hacked together" solution that has never been perfected. Synthesis tools aren't compiling like a programming language compiler, they're guessing. There is no deterministic solution (at least within computable time) for the synthesis process. It has to take shortcuts and fall on non-optimal solutions and (due to the incompleteness of Verilog or VHDL as a hardware description language) sometimes purposely translate circuits that don't have the same functionality as the actual code.
Take:
always @(posedge clk, negedge reset)
for instance. The language is describing that events only happen at the edge of the clk or the edge of reset. But among hardware designers, this syntax has become "tribal knowledge". When synthesis sees this syntax and this exact syntax, it creates an edge sensitive flip-flop with an asynchronous reset. The reset is level-sensitive, not edge sensitive.
People who aren't careful will have their circuit simulate one way (because the simulator obeys the description of the language) but synthesize into gates that behave differently.
Why is such a glaring imperfection allows? Simply put, synthesis algorithms are good at recognizing and creating synchronous circuits from a language description. They're altogether rather poor at recognizing and creating asynchronous circuits. Because async resets are so common, this special provision was put inside all synthesis tools to recognize that construct. But try describing a level-sensitive latch, a delay circuit, an asynchronous feedback circuit, etc. The tool will not handle it very well.
Those things are usually designed by hand.
I would strongly recommend "HDL Chip Design" by Douglas Smith. It's out of print, still sells for $200+ and is about the best book on chip design you'll ever have.
"What you are designing in HDL is hardware.
There's some overlap. Stuff like algorithms may be used in both arenas, but the goal of HDL is to make hardware, not programs."
Sounds pretty straightforward to me. "HDL to design hardware is not a programming language, the HDL has some overlapping features that allow you to make programs".
So let's add inability to read and comprehend a statement to your menagerie of tendencies. Don't talk about things you know nothing of just to try to boost your own ego and sound smart. You end up sounding like an idiot to anyone remotely familiar with the field.
25 Years of hardware and software engineering experience.
Who's never touched digital design from my guess. Look, code monkey, you're wrong. I've given you examples of how synthesizable Verilog does not behave like a programming language. You didn't get it. You don't want to get it. You probably saw "hey! there's an if statement! it's a program!"
Kiddie scripting for 25 years means 1. you're out of date and 2. you know nothing about hardware.
I wouldn't let you anywhere near one of my ASICs.
If you can't figure out how that's not a program (and my guess is you can't), then you're a lost cause. I'll give you a hint: it's not a program. The fact you don't understand this tells me you have absolutely no understanding of how hardware logic works and moreover are willfully ignorant and unwilling to learn.
Can lead the horse to water, etc.
As someone who understands english, my experience tells me you should learn to parse arguments better.
"Above x (fill in whatever number you want here)".
You're going off on a tangent. I know it's typical on /. to argue for argument sake in order to look smart but seriously, stay on topic.
Hardware designers give a shit. Because when designing hardware using Verilog, you don't approach it like it's a programming language. Because the programming parts of it don't work when the synthesis tool tries to map it to gates. Hence, Verilog, when designing hardware, is not programming.
An instructor is good but honestly, I've learned more from the compiler than I have from my instructors. That's why I said it's good for an introductory language. After you've learned VHDL, picking up Verilog is easy because you're already aware of all the gotcha's even if your instructor forgot them.
And frankly, for most undergrad students, if they can be sloppy and get it to work (and then go drinking), they will. No matter how much the instructor emphasizes "this may or may not work, do it the other way and it's guaranteed to work", the students won't listen. It's great to have the compiler put a stop to that and actually force them to learn the design concepts.
As for time spent, I'll use an anecdote. For my advanced digital design course as an undergrad, we designed a 32-bit MIPS processor. I did it in Verilog and put it on an FPGA. Our school didn't spend money on top-of-the-line FPGA's so we didn't have fancy features like ChipScope or JTAG debugging. Instead we had to use logic analyzers (running embedded windows and crashing a lot) and spare pins on the FPGA (there were only 12 to spare) as a test mux.
We spent weeks sleeping in the lab debugging that thing. Couldn't figure out why bits 0-8 (or so we thought) of the instruction register didn't look right even though it was executing that instruction. Turns out that because we added an integer count (in the RTL) as an offset to the address of the counter to sequence through the testmux, the address became a 32-bit value instead of the 16 we specified. And because we didn't specify which bits were to be assigned to which of the testmux select lines, synthesis just randomly did it.
That was one of many many many things that would've taken 3 seconds to correct when a VHDL compiler told you to "stop". Instead it took 14 hours. I almost destroyed that thing out of frustration.
It is a scripting language rather than compiled.
Verilog is very much compiled. Try writing a verilog module with a faulty assignment at the end and see if it'll run through even the simulation tool. It won't.
Some of the more popular simulators (VCS, Modelsim) actually create binaries out of the Verilog, associated libraries and invokes GCC for the C-models.
To ring my point home, take the following Verilog example:
module counter(preset,set,areset_n,clk,en,dout,tcnt);
parameter tcnt_val = 32'hFFFFFFFF;
input areset_n, clk, en;
input [31:0] preset;
output [31:0] dout;
output tcnt;
reg [31:0] data;
always @(posedge clk, negedge areset_n) begin
if(areset == 1'b0) begin
data = preset;
end else begin
if(preset == 1'b1) begin
data = preset;
end else begin
data = data + 1;
end
if((data + 1) == tcnt_val) begin
tcnt = 1'b1;
end else begin
tcnt = 1'b0;
end
end
end
assign dout = en & data;
endmodule
1. What is the subtle difference between how this will behave as Verilog (in a simulator) and the real circuit when areset_n is 0 from time 0? What would be a possible solution to this?
2. What are the potential problems with setting "data" to "preset" under the condition "areset_n == 1'b0"?
3. What will "data" be when "tcnt" is 1'b1?
4. Is there anything bad about assigning dout to (en & data)? What would be a reason to do that? What would be a reason to do that assignment inside the "always" block?
Lastly, if this is a program. Translate it into equivalently functional psuedo-assembly.
Except the Verilog you use for actual hardware description involves none of that. When hardware designers say "Verilog" we mean "Verilog for synthesis". Verilog allows you a programming environment that you can do all of the fancy procedural things. But when you use it to describe hardware, you're limited to a fairly small subset of the language that is anything but programming.
Nonsense. Teaching the tool is the job of a vocational program. The theory of HDL will long out-last any particular errors or syntax that come about.
Except in this case the tool is intricately related to the "theory of HDL". This isn't some "sorry, you used \r\n instead of \n" issue. VHDL compile errors are real design issues. Basic issues that every designer needs to understand.
Example:
integer count;
bit [8:0] bus;
always @(posedge clk, negedge reset) begin
if(reset == 0) begin
count = 0;
end else begin
count = count + 1;
end
end
assign bus = count;
This is all legal in Verilog. Its equivalent VHDL would throw a huge fit. Does the student who uses Verilog for this understand how it will be translated? Design Compiler will do the following things "behind the student's back" with a list of warnings inside the log that most undergrads won't bother looking at:
1. It will assign "bus" to the first 8 bits of count. This may or may not be the desired behavior.
2. It will treat count as a signed integer, it's probable that it is meant to be an unsigned counter.
3. It will optimize by encoding the counter in something other than BCD. The ambiguities of how the bits of "count" are assigned to "bus" with the encoding scheme of choice are non-obvious.
VHDL makes you explicitly describe all of these things. It may seem a "pain in the ass" but these concepts are ones that any designer should understand *before* they commit something to silicon (or SRAM in the case of Xilinx).
After you understand all of this, moving to Verilog will save you time (as long as you're careful) by letting the compiler do more of the manual translations for you.
I know you're trying to sound smart here. But it really doesn't take away from my point. Past point x (fill in whatever number you think is beyond the point of noticeability), you can run at any "stellar speed" you want and it wouldn't make a difference. Designing for slow systems with that in mind leads to not utilizing high-end systems.
I don't think there's a single synthesis tool out there that will let you synthesize a design without at least a clock. Other timing constraints aside, without a clock specification, there's ambiguities as to how to synthesize it to synchronous logic.