Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I am looking for a reality check. I have 10 years experience doing software verification on EDA tools, in particular hardware emulators, System Verilog, and VHDL. When looking at some job ads I see "required 6+ years ASIC verification experience", can any of my 10 years experience be converted? I firmly believe with the continued use of RTL coding for designs, SW quality methods can be applied. Am I deluding myself? All other requirements like "strong Verilog, Perl, and C++ programming skills" or "emulation experience" I meet. I am not sure how my years verifying synthesis and emulation tools can be translated for ASIC verification experience.Article: 127376
On Dec 19, 9:59 am, John_H <newsgr...@johnhandwork.com> wrote: <snip> > Maybe XAPP485 didn't have it terribly wrong using the CLKFX and ~CLKFX > as the inputs to the two clock buffer (that I saw as a bastardization > of the 2 approaches). If the 50% duty cycle correction is local to > the DCM and not the global clock, this inversion would work. If the > 50% duty cycle correction is global, however, the global clock > polarity that isn't part of the feedback path would be that much worse > off. <snip> Quick update: the issue I thought I had with XAPP485 wasn't an issue after all. I've been resurrecting the DCM issue after going though a coworker's design. The XAPP485 code he modified initially used the CLKFX180 after all. My memory got the better of me because of the shorthand used in the original and modified code - rxclk35not rather than rxclk35_180 or similar nomenclature - left me only with the recollection of the inverted clock in the modified code, not the original version. Also, rereading the Spartan-3 Gen User guide's DCM section with this specific topic in mind, the 50% duty cycle correction appears to be local to the DCM regardless of feedback. Since the global clock buffers don't have an inverted input as an option, I'm finally happy that the CLK180 output (and CLK270 for that matter) is available. - John_HArticle: 127377
Dwayne, I would say "go for it." Don't worry about "converting" experience: what they are asking for probably does not exist in any one human being, anyway. ASIC verification is 100% software tool exercises before silicon arrives. Once silicon arrives, ASIC verification takes more physical forms (bench, tester, system, etc. testing). "Verification" by IC designers is probably 95% of what they do (maybe even 98%); whether it is verilog or VHDL test benches, c, or c++ models, spice level simulations, or clever combinations of all of the above. The same methods used to check software quality are used to check hardware quality: checklists of what tests must be done, and under what conditions and stimuli, regression testing against past known issues, and so forth. I am surprised not see that they require a particular scripting language, as that is part of any verification "toolkit" (to automate as much of the drudgery as possible). Austin Dwayne Dilbeck wrote: > I am looking for a reality check. I have 10 years experience doing > software verification on EDA tools, in particular hardware emulators, System > Verilog, and VHDL. When looking at some job ads I see "required 6+ years > ASIC verification experience", can any of my 10 years experience be > converted? I firmly believe with the continued use of RTL coding for > designs, SW quality methods can be applied. Am I deluding myself? > > All other requirements like "strong Verilog, Perl, and C++ programming > skills" or "emulation experience" I meet. I am not sure how my years > verifying synthesis and emulation tools can be translated for ASIC > verification experience. > >Article: 127378
Thanks. I haven't been in the job market for 10 years since I got out of college. Thus, I wanted to verify my thought process. "austin" <austin@xilinx.com> wrote in message news:fkbuug$i5s3@cnn.xsj.xilinx.com... > Dwayne, > > I would say "go for it." > > Don't worry about "converting" experience: what they are asking for > probably does not exist in any one human being, anyway. > > ASIC verification is 100% software tool exercises before silicon > arrives. Once silicon arrives, ASIC verification takes more physical > forms (bench, tester, system, etc. testing). > > "Verification" by IC designers is probably 95% of what they do (maybe > even 98%); whether it is verilog or VHDL test benches, c, or c++ models, > spice level simulations, or clever combinations of all of the above. > > The same methods used to check software quality are used to check > hardware quality: checklists of what tests must be done, and under what > conditions and stimuli, regression testing against past known issues, > and so forth. > > I am surprised not see that they require a particular scripting > language, as that is part of any verification "toolkit" (to automate as > much of the drudgery as possible). > > Austin > > > Dwayne Dilbeck wrote: >> I am looking for a reality check. I have 10 years experience doing >> software verification on EDA tools, in particular hardware emulators, >> System >> Verilog, and VHDL. When looking at some job ads I see "required 6+ >> years >> ASIC verification experience", can any of my 10 years experience be >> converted? I firmly believe with the continued use of RTL coding for >> designs, SW quality methods can be applied. Am I deluding myself? >> >> All other requirements like "strong Verilog, Perl, and C++ programming >> skills" or "emulation experience" I meet. I am not sure how my years >> verifying synthesis and emulation tools can be translated for ASIC >> verification experience. >> >>Article: 127379
John_H wrote: > > Also, rereading the Spartan-3 Gen User guide's DCM section with this > specific topic in mind, the 50% duty cycle correction appears to be > local to the DCM regardless of feedback. > My recollection is that changes to the feedback path affected the forwarded global clock output duty cycle for the V2 tests I did ~5 years back at 200-300 MHz clock rates (400-600 Mbps). Could be either my that my recollection is wrong, or that I was seeing some other effect ( i.e. main delay line/feedback delay line dispersion variations ) that kicked in when I changed the feedback source or feedback deskew settings. > > Since the global clock buffers don't have an inverted input as an > option, I'm finally happy that the CLK180 output (and CLK270 for that > matter) is available. > I'd also second the worries about DCM jitter. IIRC the fed-back clk0 output has better jitter specs than the 180, giving asymmetrical sampling windows for rising/falling edges. Can you do a x7 externally? BrianArticle: 127380
On Dec 19, 3:52 pm, Brian Davis <brimda...@aol.com> wrote: <snip> > > Can you do a x7 externally? > > Brian The board was set long ago with different revisions already in the hands of various developers. Even the FPGA pinout is hard at this point. The serial receiver is working well in the units we have in house. The timing numbers on this link give me the willies, however, hence my desire to understand any nuance to improve the timing margin. I'm just sad the unused external PLL channels aren't available to the FPGA. Wouldn't that have been a nice tweak! - John_HArticle: 127381
Hi, For Modelsim XE 6.1e, it says the following on page CR-27 of command reference. I do not understand what is the "4-state binary radix". Could you tell me what it means? Thanks a lot. Searching for binary signal values in the GUI When you use the GUI to search for signal values displayed in 4-state binary radix, you should be aware of how ModelSim maps between binary radix and std_logic. The issue arises because there is no "un-initialized" value in binary, while there is in std_logic. So, ModelSim relies on mapping tables to determine whether a match occurs between the displayed binary signal value and the underlying std_logic value.Article: 127382
I'm not very experienced at SMT PCB layout, but I'm trying to design a four-layer board with an XC3S50A-4TQG144. I'm using inner layers for 3.3V (Vcco, Vccaux) and GND. Am I asking for trouble if I route Vccint on the power plane? If I do that, should I just run traces between the four Vccint pins, cutting a "+" shaped region in the power plane, or should I give Vccint a square occupying most of the area under the package? Thanks, EricArticle: 127383
Hello, I'm trying to write VHDL code that detects when two signals both rise from zero to one at the same time. Do you guys have any idea on how to do this? FPGAguyArticle: 127384
On Wed, 19 Dec 2007 18:40:17 -0800, Eric Smith <eric@brouhaha.com> wrote: >I'm not very experienced at SMT PCB layout, but I'm trying to design a >four-layer board with an XC3S50A-4TQG144. I'm using inner layers for >3.3V (Vcco, Vccaux) and GND. Am I asking for trouble if I route >Vccint on the power plane? If I do that, should I just run traces >between the four Vccint pins, cutting a "+" shaped region in the power >plane, or should I give Vccint a square occupying most of the area >under the package? > >Thanks, >Eric That works. Cut a square in the power plane, under the chip, and insert a smaller square of Vccint, so you can bring two supplies into the chip on each layer. Then you can route a fat trace in to power the inner island, with a few bypass caps, maybe on the backside of the board. JohnArticle: 127385
I wrote: > Am I asking for trouble if I route Vccint on the power plane?P John Larkin wrote: > That works. Cut a square in the power plane, under the chip, and > insert a smaller square of Vccint, so you can bring two supplies into > the chip on each layer. Then you can route a fat trace in to power the > inner island, with a few bypass caps, maybe on the backside of the > board. OK, that's what I'll do. If I was using a Spartan-3 or Spartan-3E, which also require a Vccaux of 2.5V, would it be reasonable to do the same thing to the ground plane under the chip? Thanks! EricArticle: 127386
"fpgaguy" <chongv@gmail.com> writes:
> I'm trying to write VHDL code that detects when two signals both rise from
> zero to one at the same time. Do you guys have any idea on how to do this?
Except in simulation, two signals *never* rise at the "same time".
A quick reality check for things like this is that if you can't do
something with "real" gates and flip-flops, you can't do it in
synthesizable VHDL (or Verilog) either. If you *can* do it with
gates and flops, then it's trivial to express it in VHDL (or Verilog).
If you mean that you need to detect when both signals rise within a
clock period (for some arbitrary clock), you can do it fairly easily.
For instance, if you have a 100 MHz clock, you can detect whether
the two signals rise within the same 10ns clock period. Of course,
there's the usual uncertainty if one of the signals has an edge too close
to the active clock edge, so you need some flops as synchronizers.
The following is completely untested. Provided with no warranty,
your mileage may vary, yada yada.
entity detector is
port (clk: in std_logic;
a: in std_logic;
b: in std_logic;
e: out std_logic); -- will ouptut a high pulse for one clock
end detector;
architecture rtl of detector is
signal a1, a2, b1, b2: std_logic; -- dual-rank synchronizers
signal ap, bp: std_logic; -- previous state
begin
regp: process (clk)
begin
if rising_edge (clk) then
a1 <= a; -- dual-rank synchronizers
a2 <= a1;
b1 <= b;
b2 <= b;
ap <= a2; -- previous state
bp <= b2;
end if;
end process regp;
e <= '1' when ap = '0' and a2 = '1' and bp = '0' and b2 = '1'
else '0';
end rtl;
Article: 127387On Wed, 19 Dec 2007 20:00:14 -0800, Eric Smith <eric@brouhaha.com> wrote: >I wrote: >> Am I asking for trouble if I route Vccint on the power plane?P > >John Larkin wrote: >> That works. Cut a square in the power plane, under the chip, and >> insert a smaller square of Vccint, so you can bring two supplies into >> the chip on each layer. Then you can route a fat trace in to power the >> inner island, with a few bypass caps, maybe on the backside of the >> board. > >OK, that's what I'll do. > >If I was using a Spartan-3 or Spartan-3E, which also require a >Vccaux of 2.5V, would it be reasonable to do the same thing to the >ground plane under the chip? > >Thanks! >Eric Ground planes are usually sacred, and it potentially complicates bypassing if there's no ground plane all under the chip. 6 layers is a lot more reasonable for an fpga with three powers and the usual mess of signals. And 6 doesn't cost much more than 4. You could probably get away with it, the ground cutout thing for Vccaux. I've seen a lot of strange fpga power connection schemes, and they all worked. JohnArticle: 127388
fpgaguy wrote: > Hello, > > I'm trying to write VHDL code that detects when two signals both rise from > zero to one at the same time. Do you guys have any idea on how to do this? > > > FPGAguy If Eric Smith's suggestions don't get you going, what kind of accuracy do you want? What devices are you targeting? Do you really want a digital value to say they rose within the specified window or is this part of a larger aspect - such as a phase detector - where the function doesn't necessarily have to be simultaneous rise detection, but a bigger scheme... an analog signal in the end, perhaps.Article: 127389
On Wed, 19 Dec 2007 12:08:34 -0800 (PST), KJ <Kevin.Jennings@unisys.com> wrote: >> If one pays some attention to the first 2X->X boundary (ie >> minimal or no logic in between), the STA will correctly manage the >> clock tree and there will be no problems. > >If generally true, then the OP wouldn't be having the setup problem >now would he? > I don't think I can make a judgment on that without having more details of the OP's design. >The reason he is having this warning is because of the inherent skew >between the clock to a flip flop and the output of that flip flop and >using them both as clocks which can not be 'managed' no matter how >much attention you pay. I think this is an overly strong statement. For a more general case than we're talking here (not restricted to fpgas) what is the substantial difference between a clock buffer and a clk-> Q delay of a flop? I'm assuming that you'd agree if two flops were to get their clk inputs from two separate leaves of the clock tree the skew would be manageable and it can even be done if the two branches were related higher in the tree. If one of the branches includes a flop, does the skew become not managable no matter how much attention one pays? > This is a clock domain crossing problem, and >while the frequency of the two clocks have a nominal relationship to >each other (i.e. one is 2x the other) there is NO controllable >relationship between the skew of the edges of these clocks and THAT is >what is causing the timing 'warning' and eventually a real failure. > Again no controllable relationship is a little strong in general. Imagine a clock tree with two branches and from one branch remove enough buffers to compensate for a clock->Q of a flop and insert a flop. Why do you think the skew between two branches is any less manageable than before? Or at least manageable with (sligthly) more difficulty but "no controllable relationship" ? >> This way the design will be at least as robust as treating them async >> and putting in async fifos which are quite complicated to design too.- Hide quoted text - >> >Well, I certainly wouldn't bother to write the code to implement an >async FIFOs... I was hoping that you'd say that an async fifo is not needed. Even if one can't manipulate the clock tree (as in an FPGA), the skew between a root clock and a divided clock is a fixed albeit unknown (actually known, exactly the clk->Q of one flop but not compensated in the clock tree) one so what is needed is at most a synchronous fifo. An asynchronous fifo would work but it is definitely unnecessary and overkill. A divided clock doesn't require a clock domain crossing solution where the rates of the two clocks have a changing relationship over time like having two clocks with very similar frequency with a couple of hundred ppm difference where an async fifo is called for.Article: 127390
Altera has the lib in the altera quartus directory! There are e.g. "eda/simlib". Ther you have to compile several *vhd / *v into your libs. Typical : "altera" lib holds the altera primitives, "altera_mf" has the megafunctions and so on. I do not have a sheet here in my office but could provide you with acomplete list. Henk ten BakkerArticle: 127391
perhaps this is amoing others one of the mysteries, Xilinx likes us to explore with this wonderfull board ... Henk, (owning a SPARTAN 3E board and not knowing, what to to with it ...)Article: 127392
is there a reason why not use the mega wizzard? I have a Stratix II GX running with various DP-RAMs.Article: 127393
I'd also be interested in a WORKING example of the DDR SDRAM on this board. I asked this quastion already and had been pointed to examples allrady too - but no success so far.Article: 127394
Hi, I have a XC3S400 based design with an XCF02 and I am finding I can't program the FPGA unless I power cycle it first. If I program the XCF02 it works fine - I'd rather program the FPGA for testing though, it's quicker for a start :) I am not really sure where to start since I designed the board myself (although it is closely based on the Memec 3SLC eval board we have), I am using XC3Sprog (because I don't actually run Linux), and I am an FPGA noob :) Any hints or suggestions gratefully received. Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 127395
I would agree on the ground layer always because it is common to all power rails. We do have a product on 4 layers that has 7 power segments(4 Vccio, 1.2V, 2.5V and 3.3V) under the FPGA and so far with many hundreds of them in the field with many different customers no reports of power related issues. I will say we did a lot of work to make all of the power segments as good as we could using a number of techniques that we use frequently. The product in question is here http://www.enterpoint.co.uk/moelbryn/raggedstone1.html. On this product we targetted 4 layers because we wanted to make a price target and 6 layers does cost more if only by a few dollars or the equivalent. If you are doing small numbers then PCB tooling may be of significance and that will be dearer on 6 layers than 4 layers. Standard lead times will also be greater on 6 layers than 4 usually 1-2 days and fast turn will cost more for a given target turn time. John Adair Enterpoint Ltd - Home of CR1. The FPGA Automotive Interface Solution. On 20 Dec, 04:30, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Wed, 19 Dec 2007 20:00:14 -0800, Eric Smith <e...@brouhaha.com> > wrote: > > > > > > >I wrote: > >> Am I asking for trouble if I route Vccint on the power plane?P > > >John Larkin wrote: > >> That works. Cut a square in the power plane, under the chip, and > >> insert a smaller square of Vccint, so you can bring two supplies into > >> the chip on each layer. Then you can route a fat trace in to power the > >> inner island, with a few bypass caps, maybe on the backside of the > >> board. > > >OK, that's what I'll do. > > >If I was using a Spartan-3 or Spartan-3E, which also require a > >Vccaux of 2.5V, would it be reasonable to do the same thing to the > >ground plane under the chip? > > >Thanks! > >Eric > > Ground planes are usually sacred, and it potentially complicates > bypassing if there's no ground plane all under the chip. > > 6 layers is a lot more reasonable for an fpga with three powers and > the usual mess of signals. And 6 doesn't cost much more than 4. > > You could probably get away with it, the ground cutout thing for > Vccaux. I've seen a lot of strange fpga power connection schemes, and > they all worked. > > John- Hide quoted text - > > - Show quoted text -Article: 127396
Eric Four layers is trivial. Layer stack is Signal gnd 3v3 signal. Use sot23 style linear regs for 1v2 and 2v5 (for the 3e) and place them on the underside, within the FPGA. Then use the two signal layers to pour 1v2 and 2v5 to the fpga. The only limitation (for the 3e) is that all signals have to exit outwards from the FPGA. ColinArticle: 127397
"austin" <austin@xilinx.com> wrote in message news:fkbuug$i5s3@cnn.xsj.xilinx.com... > Dwayne, > > I would say "go for it." > > Don't worry about "converting" experience: what they are asking for > probably does not exist in any one human being, anyway. > > ASIC verification is 100% software tool exercises before silicon > arrives. Once silicon arrives, ASIC verification takes more physical > forms (bench, tester, system, etc. testing). > > "Verification" by IC designers is probably 95% of what they do (maybe > even 98%); whether it is verilog or VHDL test benches, c, or c++ models, > spice level simulations, or clever combinations of all of the above. > > The same methods used to check software quality are used to check > hardware quality: checklists of what tests must be done, and under what > conditions and stimuli, regression testing against past known issues, > and so forth. > > I am surprised not see that they require a particular scripting > language, as that is part of any verification "toolkit" (to automate as > much of the drudgery as possible). > > Austin I agree with Austin, just go for it, in the worst case you come out with some extra experience on how to handle a job interview. I would however advise you to have a quick google on some of the verification techniques (if you don't already know them) such as functional coverage, assertions based verification, constraint random and transaction level modelling, nothing fancy just understand their advantages and disadvantages and some of the languages they use. Having said that I suspect a lot of verfication is still done using nothing more than a VHDL/Verilog testbench in a similar trend to some FPGA engineers just loading the design on the board and see if it works :-) Hans www.ht-lab.comArticle: 127398
>is there a reason why not use the mega wizzard? >I have a Stratix II GX running with various DP-RAMs. > I suspect that the O/P was trying to avoid having technology-dependent RTL files and hence aid reuse. However, it looks like the synthesis tools will thwart his worthy aim!Article: 127399
>Hi, >For Modelsim XE 6.1e, it says the following on page CR-27 of command >reference. I do not understand what is the "4-state binary radix". >Could you tell me what it means? Thanks a lot. > > >Searching for binary signal values in the GUI >When you use the GUI to search for signal values displayed in 4-state >binary radix, you >should be aware of how ModelSim maps between binary radix and >std_logic. The issue >arises because there is no "un-initialized" value in binary, while >there is in std_logic. So, >ModelSim relies on mapping tables to determine whether a match occurs >between the >displayed binary signal value and the underlying std_logic value. > 1. "binary radix" indicates how the signal/variable values are displayed in the Wave or List window, alternative radices are decimal, hexadecimal, user-defined etc. 2. Values for "binary" signals in "the real world" need more than 2 states, to cover "unknown", "high-impedence", "don't care", and strong/weak drives. VHDL 'std_logic' models them with 9 states, Verilog has a simpler 4 state model. 3. When searching for a binary value, such as "10101010" in an 8-bit signal, the table under the quoted text indicates that some of the additional states may cause a match, which may or may not be what you were expecting before you read the Command Reference. 4. This probably won't cause you much distress. 4. It probably won't be in the exam, either.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z