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
Mike Oxlarge wrote: > On Wed, 04 Jan 2006 11:36:30 -0800, Andy Peters wrote: >>The simple rule to remember is that you can't assign to a signal in >>more than one always block. Put the synchronous reset curval <= 5; in >>the negedge-clocked block. >> >>-a > > > I get what you're saying, and have tried your (and the other's) suggestion > of putting the reset in the negedge-clocked block, and it synthesizes just > fine. However, I'm now trying to implement what mk suggested: > > <quote mk> > ... > You don't need a two phase implementation which necessiates mixed clock > edges. You can do everything you need with a single edge. Imagine a cloud > of logic which takes your enable and the cnt value and calculates the next > value of cnt to be presented. When the clock edge happens this value gets > to the flop output and the cycle starts again. > ... > </quote mk> > > Any ideas on how I can implement what he suggested? I'm working on it, but > not making much progress. I'm sure there's probably a simple and elegant > solution to this that I'm missing. > My suggestion would be eliminate using both the posedge and negedge conditions in your design and just use posedge for the clock edge. You have created a half-cycle path in your design when it appears that you have no need to do so. This will likely lead to a race condition (aka hold violation) where some of the data gets through the other edge when it shouldn't have or a setup violation where the data doesn't get to the register on the other edge in time. Unless you really need to use opposite edges for a very specific timing reason you should avoid doing so it minimize lengthy debug sessions where the design works when it's cold and then starts to fail when it warms up or the reverse. EdArticle: 94026
"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag news:1136404826.510529.30510@z14g2000cwz.googlegroups.com... > Xilinx does not discriminate against Europe. > It was the other way around: > I used a friend who flew home to Germany for Xmas, to hand-carry a kit, > and mail it locally to Antti. > So Antti got the first kit outside the US. > We cannot do that for everybody in Europe. Maybe it was "the squeaky > wheel gets the grease..." > In the meantime, we are mailing Antti another board, since we don't > want him to be a complaining repairman... > Peter Alfke > Ouch - I did not want to complain so much actually, I was just eager to get some things tested, and when the power supply surge did burn everything, so I tried to repair as much as could - and I am now actually able to use the board again to some degree. Spartan3e was pretty much the only silicon device on my burnt board that retained some useability, everything else was totally dead - this should be taken as very good destructive test of the Spartan3e silicon. So I am not complaining about the need of repair, things happen - actually similar power supply has damaged here several other boards - so it was defenetly not the fault of the board or useage. Anyway I had and still have fun with Spartan3e and even havent checked all the new features yet. And I hope that my bad-luck at the beginning of my Sample Pack testing actually brings something useful out of it at least I was forced todo lots of more testing then I would otherwise done. As of US vs Europe, well at first the Distributors provided the "Free" special but later on it turned out that those are only valid in the north america and asia/pacific, this was kind of surprising, but OTOH maybe those specials at those disti sites were ahead of time, as well Xilinx website has still no Sample Pack info (or almost none). I just collected the public info and provided that, somewhat assuming there will be (some)EU supply also. More to the Europa - it looks like nahitafu in Japan got his S3e sample pack a day or two before I did (or maybe even earlier) Peter, I just (1 minute ago) received confirmation that first beta test person testing the Sample Pack standalone programming utility was actually able to use the tool and to reprogram the flash on his board - I keep working on and hope to get the tool soon available for public release. AnttiArticle: 94027
Parkov, I would invest my time in learning a HDL: VHDL or Verilog. Schematic entry for logic design is (almost) completely dead. It has become rare to find anyone doing anything in schematic form, except for the highest level where the pins are connected. All of the levels of logic are described in hardware design language (HDL) modules. To pick a vendor based on their 'schematic tool' is probably the least interesting criteria. Picking the vendor based on: -available technology -speed -power -features -cost -size -package -ease of use of software tools -available synthesis tools -available simulators -FAE support -web support -part availability all makes sense. AustinArticle: 94028
Mike, I'm pretty sure you understand this, but others may not: The problem is not in having multicycle or false paths in a design; it is in having constraints that relax timing requirements on those paths that is the problem. If the entire design p&r's and meets STA without any of the above constraints, great, problem solved. But if it does not, and you include the constraints, then there is a problem in that the constraints may relax timing on paths that really are not multicycle (or false), and then only a full timing sim will reveal it (and then only if that particular path is exercised by the sim!). In fact even if you don't include constraints to pass static timing, but just review the violations and rationalize them as false/multicycle paths, you really have the same problem in verifying the rationalizations. There are some cases where including multicycle and false path constraints prior to synthesis can resolve timing issues elsewhere in the design, by not consuming critical resources where they are not needed, thus reserving them for truely critical paths. Whatever the reason/result of including these constraints, they must be verfied just like the RTL code, but the only way to do it (without a custom formal analysis tool) is with full timing sim, excersizing the paths so constrained. Your point about detailed design loop vs release check-off is a good one. I assumed we were talking about check-off, since I never run full timing until then anyway. AndyArticle: 94029
Austin Lesea wrote:
> I would invest my time in learning a HDL: VHDL or Verilog.
Good advice, but allow several months.
> Schematic entry for logic design is (almost) completely dead. It has
> become rare to find anyone doing anything in schematic form, except for
> the highest level where the pins are connected.
The one place it isn't dead is for
circuit-board oriented, first-time
cpld users copying some glue logic
off of an application note.
-- Mike Treseler
Article: 94030>The one place it isn't dead is for >circuit-board oriented, first-time >cpld users copying some glue logic >off of an application note. Thats about where I'm at. No worries, I'm checking out the two HDL variants, just wanted to get a couple things rolling fast in the meantime. I'm coming from a 74xxx chip to chip background so I already have some designs on paper. Thanks for the heads up everyone on the Quartus recomendation.Article: 94031
Mike Treseler <mike_treseler@comcast.net> wrote: > Austin Lesea wrote: > > I would invest my time in learning a HDL: VHDL or Verilog. > Good advice, but allow several months. But schematic entry oftem leads to non-registered designs, where you should allow several month of debugging too... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 94032
Andy wrote:
> The problem is not in having multicycle or false paths in a design; it
> is in having constraints that relax timing requirements on those paths
> that is the problem.
I agree with your posting.
My preference is to constrain only
Fmax and to meet STA by design only.
You are correct that this can consume some
resources, but it also saves time
and reduces stress.
-- Mike Treseler
Article: 94033I started with Ray Andraka's papers, "A Survey of CORDIC algorithms...", and "High Performance DDC for FPGAs". From the second paper it seems that DDS approaches with phase resolution larger than 10 bits or so should be done with other methods, such as CORDIC. Using the CORDIC should also give you the complex mix for free. I'm thinking that you would put your real input into x, set y to zero, and then put in a phase accumulated value for your desired channel LO value. Then you can get out a "de-rotated" I and Q from the X and Y outputs. There's some quadrant mapping in there too. I'm going to start hacking on one of the Xilinx System Generator CORDIC blocks (SINCOS?) to get what I need. In practice, how many iterations or PEs do you need to get a significant SFDR such as 96dB? With DDS functions there's a formula ceil(SFDR/6) for the phase width. Is there something similar for a CORDIC implementation? For the 96dB phase-dithered DDS, I'm seeing 15 Block RAMs required, which is expensive. I'm assuming the cores (Sysgen blocks) are using quarter-wave tables? The Taylor-series DDS drops down the RAM but requires multipliers. Thanks for any suggestions, BradyArticle: 94034
I was playing with a CORDIC implementation approach but with lower (12-bit) phase resolution with a very tiny footprint (no memory). Is your demodulation from 50MS/s+ or 10MS/s- data? I'd be interested to see if I could extend the performance to your needs. Basically I'm pursuing bit-serial manipulation of I/Q data *and* phase to give lower error in the LSbits of the CORDIC stages. I was considering a 16X clock relative to the I/Q data but saw that I might double the performance without doubling the footprint. The errors from the multiple add/subtract stages need to be included in the SFDR to figure the number of bits of precision needed and should be your overriding "tweak." Adding another 5 stages of fine phase resolution don't do you any good if the arithmetic errors are large. I don't know of - but haven't looked for - a general fomula for the SFDR but one of Ray's papers discusses the arithmetic errors. Care to share your requirements? If you use 1 BlockRAM for 9 bits of phase in a 1/8th wave sine/cos lookup (for a total of 12 phase bits) you can have a second 9 bits of lookup (because you have 9 bits available at the BlockRAM address) for the sine/cos of the phase remainder in a second BlockRAM. Standard sin(x+d) transform. The total number of multiples should be 6 and the total memory: 2 BlockRAMs. If you can spare *those* resources, the approach is a smaller footprint than a 1-stage DDS demodulator and provides exceptional dynamic range. "bgaughan" <bgaughan@airnetcom.com> wrote in message news:1136412913.561951.194570@z14g2000cwz.googlegroups.com... >I started with Ray Andraka's papers, "A Survey of CORDIC > algorithms...", and "High Performance DDC for FPGAs". From the second > paper it seems that DDS approaches with phase resolution larger than 10 > bits or so should be done with other methods, such as CORDIC. > > Using the CORDIC should also give you the complex mix for free. I'm > thinking that you would put your real input into x, set y to zero, and > then put in a phase accumulated value for your desired channel LO > value. Then you can get out a "de-rotated" I and Q from the X and Y > outputs. There's some quadrant mapping in there too. > > I'm going to start hacking on one of the Xilinx System Generator CORDIC > blocks (SINCOS?) to get what I need. In practice, how many iterations > or PEs do you need to get a significant SFDR such as 96dB? With DDS > functions there's a formula ceil(SFDR/6) for the phase width. Is there > something similar for a CORDIC implementation? > > For the 96dB phase-dithered DDS, I'm seeing 15 Block RAMs required, > which is expensive. I'm assuming the cores (Sysgen blocks) are using > quarter-wave tables? The Taylor-series DDS drops down the RAM but > requires multipliers. > > Thanks for any suggestions, > BradyArticle: 94035
Parkov wrote: > >The one place it isn't dead is for > >circuit-board oriented, first-time > >cpld users copying some glue logic > >off of an application note. > > Thats about where I'm at. No worries, I'm checking out the two HDL > variants, just wanted to get a couple things rolling fast in the > meantime. I'm coming from a 74xxx chip to chip background so I already > have some designs on paper. Thanks for the heads up everyone on the > Quartus recomendation. And be sure to try out the 7400 series library that is provided with Quartus too, to make your transition easier. Once you have your design working use the Quartus builtin Verilog or VHDL synthesizer to expand your knowledge of FPGA design. Quartus allows mixed mode designs so that you can create design blocks as a schematic or HDL. Hope this helps, Subroto Datta Altera Corp.Article: 94036
Uwe Bonnes wrote:
> But schematic entry oftem leads to non-registered designs, where you should
> allow several month of debugging too...
I was playing the OP's advocate here,
because I started out where he is now.
Certainly HDL is the clean way to go.
But I also know that many hardware guys
will try it the "quick" way first.
-- Mike Treseler
Article: 94037Parkov wrote: >>The one place it isn't dead is for >>circuit-board oriented, first-time >>cpld users copying some glue logic >>off of an application note. > > > Thats about where I'm at. No worries, I'm checking out the two HDL > variants, just wanted to get a couple things rolling fast in the > meantime. I'm coming from a 74xxx chip to chip background so I already > have some designs on paper. Thanks for the heads up everyone on the > Quartus recomendation. There is also a 'middle ground', between VHDL and Schematics : Use a Boolean Eqn language, such as Xilinx have ABEL ( but for CPLD only, which here is OK ), Altera have AHDL ( I think still alive for CPLD ? ) Atmel have WinCUPL for CPLD, includes functional simulation, so can create test vectors, to allow 100% chip functional test at PGM time. This flow works best on smaller PLDs that are pgmd off-board. Lattice also have ABEL, not sure on their plans for ABEL-MachXO support ? There is a large installed base of ABEL/Boolean EQN code for CPLDs, so if they want to migrate those designs to MachXO, that would be an important flow. ICT have WinPLACE If you start to need timing simulation, then you need to align to the simulation tools. What complexity/package of CPLD do you expect to use ? -jgArticle: 94038
Hi Jim. As far as I can forsee, all that I would need are either Altera EPM3032A/3064A's or Xilinx's XC9536/XC9576 both in 44pin packages. If I went into a Boolean Equation Language, is ABEL or AHDL easier to learn/use? I can't seem to find any head to head comparisons. Is Xilinx going to continue support for ABEL for their CPLD's and is Altera going to continue support for AHDL for theirs? I know that these are not practical languages for complex FPGA design, but that doesn't need to be the issue. Tks.Article: 94039
I have a psb core written in verilog which interfaces the dual pci bridge( POWERSPAN II) friom tundra with virtexII pro. This bridge is an interface between the PSB bus on the fpga side and the pci bs on the host side. I want to configure the bridge to do dma transfer from the fpga to the 32 bit pci on the host. I went through the powerspan II data sheets and have a rough idea of the architecture . Before that I have to configure the bridge . I needed some help on configuring the bridge using vhdl. Has anyone written a code to configure the pci bridge before? Thanks, NiteshArticle: 94040
Jan Decaluwe wrote: > Hi all: > > I'm pleased to announce the release of MyHDL 0.5. > > MyHDL is an open-source package for using Python as a hardware > description and verification language. Moreover, it can convert > a design to Verilog. Thus, MyHDL provides a complete path > from Python to an FPGA implementation. > > MyHDL 0.5 has many new features, in particular with regard to > conversion to Verilog. The converter automates certain tasks > that are hard in Verilog directly. The Verilog output code > works well with popular FPGA synthesis tools. > > For a complete overview, go here: > http://myhdl.jandecaluwe.com/doku.php/overview > > The manual is here: > http://www.jandecaluwe.com/Tools/MyHDL/manual/MyHDL.html > > To find out the details of what's new, go here: > http://myhdl.jandecaluwe.com/doku.php/whatsnew:0.5 > > You can download the release from SourceForge: > http://sourceforge.net/project/showfiles.php?group_id=91207 > > Best regards, > > Jan Decaluwe Looks impressive, and interesting. Do you have any Simulation benchmark indications, and any simple, example 'complete' side-by-side projects ? By simple, I mean things like 16/24/32 bit Up/Dn/ReLoad counter, perhaps a DDS as well, and since it seems to have good ROM/RAM support, a 7 segment display counter ? -jgArticle: 94041
Parkov wrote: > Hi Jim. > > As far as I can forsee, all that I would need are either Altera > EPM3032A/3064A's or Xilinx's XC9536/XC9576 both in 44pin packages. Atmel's ATF1502 / 1504 would also be in that category. ( as would Lattice MACH4000 series ) Why not also the Coolrunner ? > > If I went into a Boolean Equation Language, is ABEL or AHDL easier to > learn/use? I can't seem to find any head to head comparisons. Is > Xilinx going to continue support for ABEL for their CPLD's and is > Altera going to continue support for AHDL for theirs? Good questions, someone in Xilinx / Altera / Lattice could answer that ? I do know from a 'tough' Xilinx.ABEL user, that Xilinx improved their ABEL flows, for CPLDs in recent releases - In their ABEL flow they now use (IIRC) VHDL as the 'back end' and ABEL as the front end. This allows them to hook-into timing simulation tools, but does loose ABEL's test vector generation ? (useful only on smaller packages) One they have that, of course, then 'continued support' is inherent, as the ABEL is only a front end. That can't have been trivial to do, so I was impressed - but it does indicate how much CPLD code is out there, in ABEL/Boolean EQN. In a similar vein, of using HDL's as 'back ends languages', see Jan Decaluwe's posting today of MyHDL : Python -> Verilog. -jgArticle: 94042
bgaughan wrote: > I started with Ray Andraka's papers, "A Survey of CORDIC > algorithms...", and "High Performance DDC for FPGAs". From the second > paper it seems that DDS approaches with phase resolution larger than 10 > bits or so should be done with other methods, such as CORDIC. > > Using the CORDIC should also give you the complex mix for free. I'm > thinking that you would put your real input into x, set y to zero, and > then put in a phase accumulated value for your desired channel LO > value. Then you can get out a "de-rotated" I and Q from the X and Y > outputs. There's some quadrant mapping in there too. > > I'm going to start hacking on one of the Xilinx System Generator CORDIC > blocks (SINCOS?) to get what I need. In practice, how many iterations > or PEs do you need to get a significant SFDR such as 96dB? With DDS > functions there's a formula ceil(SFDR/6) for the phase width. Is there > something similar for a CORDIC implementation? > > For the 96dB phase-dithered DDS, I'm seeing 15 Block RAMs required, > which is expensive. I'm assuming the cores (Sysgen blocks) are using > quarter-wave tables? The Taylor-series DDS drops down the RAM but > requires multipliers. > > Thanks for any suggestions, > Brady > Brady, The larger BRAMs in recent devices have pushed the phase resolution achievable using BRAMs up a little. 12-14 bits is possible. The CORDIC rotator phase resolution improves by one bit per iteration. For 96 dB, you'll need iterations 0-16 (working from the top of my head here). It is basically the same formula ciel(sfdr/g) but using the combination of the phase error of CORDIC and the phase resolution of your phase input. The quadrant mapping can be done with either of the reduction rotations I mentioned in the CORDIC survey paper. I'm not sure the Xilinx CORDIC core does that or not (I have my own).Article: 94043
John_H wrote: > I was playing with a CORDIC implementation approach but with lower (12-bit) > phase resolution with a very tiny footprint (no memory). Is your > demodulation from 50MS/s+ or 10MS/s- data? I'd be interested to see if I > could extend the performance to your needs. Basically I'm pursuing > bit-serial manipulation of I/Q data *and* phase to give lower error in the > LSbits of the CORDIC stages. I was considering a 16X clock relative to the > I/Q data but saw that I might double the performance without doubling the > footprint. > > The errors from the multiple add/subtract stages need to be included in the > SFDR to figure the number of bits of precision needed and should be your > overriding "tweak." Adding another 5 stages of fine phase resolution don't > do you any good if the arithmetic errors are large. I don't know of - but > haven't looked for - a general fomula for the SFDR but one of Ray's papers > discusses the arithmetic errors. > > Care to share your requirements? > > If you use 1 BlockRAM for 9 bits of phase in a 1/8th wave sine/cos lookup > (for a total of 12 phase bits) you can have a second 9 bits of lookup > (because you have 9 bits available at the BlockRAM address) for the sine/cos > of the phase remainder in a second BlockRAM. Standard sin(x+d) transform. > The total number of multiples should be 6 and the total memory: 2 BlockRAMs. > If you can spare *those* resources, the approach is a smaller footprint than > a 1-stage DDS demodulator and provides exceptional dynamic range. > You do have to make sure you carry enough extra LSBs in the CORDIC rotator to keep the rounding or truncation errors from accumulating into your output lsb. It turns out it is fairly easy to round at each stage in the CORDIC only adding one extra bit to the bottom of each adder. This works because one input to each adder is shifted, while the other is not. You are only rounding off the lsbs of the shifted input, so adding a '1' below the lsb of the unshifted input reduces the bias. As long as you keep the accumulated I and Q path rounding errors below the lsb error at the output, those won't contribute significantly to the sfdr. The accumulated error is bounded by roughly log2(iterations) bits (I've got it in a spreadsheet somewhere)... that means adding log2(iterations) extra lsbs under the output lsb. For the look-up table approach, you can use a dual port block RAM with a sine table in it. You access one port with the sine address, and the other port with the cosine address, which is modified from the sine address. For a full cycle table, the address modification is just adding 1 to the top two bits. For a quarter cycle table it is a little more complicated. By using both ports to access different points in the same table you cut the real estate needed for your sine/cos tables in half. In virtex4, the CORDIC is at a significant performance disadvantage because the fabric carry chains are quite slow compared to the speed of the DSP48 slices and memory. The DSP48's are really not set up for attempting to do CORDIC using them, and if you did, you'd give up all those multipliers.Article: 94044
Now I read a risc8 and a minimips cpu core ,and I want to know how can I get the hex file for simulation.I don't have the associate c compiler and assembly tools.Article: 94045
On Wed, 04 Jan 2006 12:18:48 -0800, Mike Oxlarge
<oxlargeMike@yahoo.com> wrote:
> However, I'm now trying to implement what mk suggested:
To be frank I am not sure what your code is trying to do but let me
start it here and you can fix it the way you want:
always @ (posedge clk) begin
if (reset) begin
curval <= 5;
acnt <= 2'h0; // nice clean value
end
else begin
case (acnt)
0: cnt <= curval;
1: cnt <= ov1;
2: cnt <= 2;
3: cnt <= 3;
endcase
if (!enable)
acnt <= acnt + 1;
if (enable) begin
ov1 <= curval;
curval <= curval + 1;
end
end
end
As there is no specific reason I can see for you to have the negedge,
put all your code into the posedge. If the behavior is not what you
want, change it till you get it right. One thing you can do is to put
all the code between the first else to the end of code in a
combinational always block so that not all variables are registered or
you don't have to wait for unnecessary cycles to get curval+1 etc.
HTH.
Article: 94046Hello. How can I see what the the clock skew is between a set of register? The clock is an output of a DCM. Also, how can I force the PAR to maintain a certain timing spec? Thanks, RobArticle: 94047
I'm looking for some suggestions as to what else to look at to fix this problem: Using a Virtex II xc2v40 and xcf02s prom connected in master serial mode. JTAG is also implemented. We've built around 50 of these boards without this problem so I believe it's just this particular board. It intermittently doesn't configure on power up. A power chip holds INIT_B low until 3.3v is 3v to delay configuration, not really needed since power ramps up in around 5ms. When it fails, I see on a scope that INIT_B never goes high after power is up and PROG is high. PROG is pulled up to 3.3v thru 4.75k. When it works, INIT_B goes high within 5ms of PROG going high. As a test, I connected PROG to GND with a wire and then powered up the board. After say 5 secs, I disconnected GND, and sometimes INIT_B would go high as expected, But sometimes it would remain low. If it went high, I could pulse PROG low and INIT_B would work as expected everytime. When the fpga is in its nonworking state, it doesn't respond on the JTAG port either. I lifted the prom pin and the power chip connected to INIT_B to verify that when it fails, it's the fpga that is holding INIT_B low and not the other chips. Any ideas on what else to look at?Article: 94048
Jim Granville wrote: >> If I went into a Boolean Equation Language, is ABEL or AHDL easier to >> learn/use? I can't seem to find any head to head comparisons. Is >> Xilinx going to continue support for ABEL for their CPLD's and is >> Altera going to continue support for AHDL for theirs? > > > Good questions, someone in Xilinx / Altera / Lattice could answer that ? Further to this, I went to the Lattice web site http://www.latticesemi.com/products/designsoftware/isplever/ispleverstarter.cfm It says "ispLEVER-Starter Primary Module (212 MB) This module is required to run the ispLEVER Starter software, and should be installed first. It includes the ispLEVER Project Navigator, and all the tools and device libraries you need to implement a design in Lattice's newest and most popular CPLD products. Note: This module supports ABEL, EDIF and Schematic design projects only. For Verilog or VHDL design project support, you must download one of the Synthesis modules listed below." ... Device Support FPGA: LatticeECP: ECP6 LatticeEC: All LatticeXP: XP3, XP6 CPLD: MachXO: All ispMACH 4000 ispXPLD 5000MX So, since MachXO is clearly in the "newest and most popular CPLD products" category, this web page is saying ABEL support for MachXO is there. Call me cynical, but I'd believe that more if a Lattice FAE was able to verify that ? -jgArticle: 94049
Mike Treseler wrote: > Austin Lesea wrote: > >> I would invest my time in learning a HDL: VHDL or Verilog. > > > Good advice, but allow several months. > And frequent use. It isn't worth learning either one for a one-time deal. If he only does a CPLD once in a blue moon and doesn't use the HDL for anything else, he'll forget more than he remembers and will have to learn it all over again next time.
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