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
On 07/13/2012 05:37 PM, rickman wrote: > On Jul 13, 11:20 am, o pere o<m...@somewhere.net> wrote: >> On 07/11/2012 01:23 PM, o pere o wrote: >> >> >> >> >> >> >> >> >> >>> Hi, >> >>> I am not an FPGA expert although this is not my first design. The >>> problem that I am having for two days now, is that I am observing >>> different results when simulating a design in GHDL and in Modelsim >>> ALTERA starter edition. >> >>> The design includes a shift register. The significant code is: >> >>> read_sro : process(s_sample) >>> begin >>> if rising_edge(s_sample) then >>> if ... --irrelevant here >>> end if; >>> if ... >>> end if; >>> if sr_burst_ena = '1' then --First phase: store data in shift_reg >>> new_data<= sr_sro_wave& new_data(c_burst_no-1 downto 1); >>> elsif dec_shift_ena = '1' then --Second phase: rotate data >> >>> new_data<= new_data(0)& new_data(c_burst_no-1 downto 1); >> >>> --irrelevant, but included for completeness >>> max_cnt<= max_cnt + 1; >>> if usum> max then >>> max<= usum; >>> max_pos<= max_cnt; >>> end if; >>> end if; >>> end if; >>> end process read_sro; >> >>> the clock signal s_sample is obtained from the main 50 MHz clock with >>> the following process: >> >>> sr_signals : process(clk) >>> begin >>> if rising_edge(clk) then >>> if sr_clear = '1' or sr_burst_ena = '1' or dec_shift_ena ='1' then >>> s_sample<= not s_sample; >>> end if; >>> ... >>> end if; >>> end process sr_signals; >> >>> I have uploaded some screenshots here: >> >>> 1- ghdl+gtkwave resulthttp://tinypic.com/r/wklimq/6 >>> 2- simulinkhttp://tinypic.com/r/2le743t/6 >> >>> It may be seen that the input signal (top signal in the GHDL result and >>> third from the top in SIMULINK) is zero during the first 5 s_sample >>> clocks, then is at one during 10 clocks and zero again for the rest of >>> the (up to 20) clocks. >> >>> The GHDL simulation shows up ok, with the register correctly loaded with >>> 0000011111111110000 after the 20 clocks, however Altera's quartus gives >>> 00000111110000011111. >> >>> Exactly the same file is being fed to to Quartus II for synthesis!! But >>> Alteras RTL (and gate level) simulations do not behave as intended. >> >>> Is there something with the coding style than can make Quartus infer an >>> absolutely different behaviour? Any help is very much appreciated!! >> >>> Pere >> >> Thanks to everybody for your inputs. Making the whole design work on >> only one clock (with suitable enables) solves the issue. This is really >> not a surprise. >> >> However, I still have some questions on this. If I built my design from, >> lets say, discrete components, I might have problems with setup and hold >> times at the shift register (SR) input, but I would NEVER EVER get the >> results that showed up in the simulation: >> >> The SR was initially cleared. The serial input to the SR is zero at the >> first clock but, surprisingly, a one appears at the 9th (!!) SR output >> after the first edge of the clock. Can anybody find a plausible >> explanation for this? >> >> The second question is, is there a way to tell Quartus that it should >> synthesize something that resembles the physical circuit? I did tell >> Quartus that s_sample was a clock (and told the frequency), however this >> was obviously not sufficient. Any thoughts? >> >> Pere > > I can't answer question one, but the answer is in the code and the > simulation. If necessary you will need to step through the code that > assigns a value to the SR, but the answer will be there. The real > point is that it doesn't matter really. The simulation told you > something was wrong and you found the problem. Is it important to > understand how the error was generated? Well, I am now just curious to know what happened to cause this behavior. Most of us learn much more from errors than from blindly following the rules. And I already looked at the code (actually I posted the lines that update de SR) and I also looked at the synthesized circuit. Nothing special there! > The second question is easy. You don't tell the tool what the > "physical circuit" is really. The tool tells you! Telling Quartus > that your clock is a clock shouldn't be needed as it can figure that > out because the signal is clocking FFs. There was no problem with the > tool. The problem was exactly as KJ described in his first post, once > you create a clock from logic, you can't control the skew between the > two clocks and so lose control over setup and hold times. The tool > also looses control over this as it depends on things the tool can't > control or even know about, the exact detailed timing of the chip. I can follow this reasoning. However, the result of this should be a setup or hold time violation signaled by the simulator, shouldn't it? But the simulator did NOT show any of them. Instead, a completely bogus behavior was observed. Nothing special was reported except the result being completely wrong. > In summary, generating clocks is bad ju-ju. Don't cross the beams. Ok. I will highlight this dogma once more ;) > Rick Thank you for your time! PereArticle: 154026
On Friday, July 13, 2012 11:20:27 AM UTC-4, o pere o wrote: > However, I still have some questions on this. If I built my design from,= =20 > lets say, discrete components, I might have problems with setup and hold= =20 > times at the shift register (SR) input, but I would NEVER EVER get the=20 > results that showed up in the simulation: >=20 Yes you could. If you built a circuit with exactly the timing delays that = were the result of simulation and did so with the same type of components u= sed in the FPGA implementation (i.e. LUTs and FFs). It's probably not very= likely that anyone could actually physically build such an accurate model = out of discrete parts, but the point is that the simulator is not lying to = you. It simulated a model that was provided to it. > The SR was initially cleared. The serial input to the SR is zero at the= =20 > first clock but, surprisingly, a one appears at the 9th (!!) SR output=20 > after the first edge of the clock. Can anybody find a plausible=20 > explanation for this? >=20 Timing violation. In this case, it was most likely that a setup time requi= rement was violated. The cause of this violation was due to the skew betwe= en the two clock domains and the signals that crossed from one to the other= . Since you have the detailed model, you would have to track that one down an= d since you are rightly interested in getting to the bottom of this you sho= uld do so. The method I would suggest you follow is to use the original RT= L that works as you expect as the 'golden' model and compare the simulation= results to that of the 'failing' model. One way to do this is to - Create a testbench that instantiates both models - Connect all inputs to both models - Run the simulation up until the outputs of the two models diverge - Look at the input to the logic that creates the failing output and determ= ine if why the output is wrong (which is generally because the input is wro= ng...which means you iterate on this step until you finally come across the= root cause signal that started the cascade of bad) > The second question is, is there a way to tell Quartus that it should=20 > synthesize something that resembles the physical circuit? I did tell=20 > Quartus that s_sample was a clock (and told the frequency), however this= =20 > was obviously not sufficient. Any thoughts? >=20 Unless you describe your logic in the form of lookup tables and flip flops,= Quartus will never be able to "synthesize something that resembles the phy= sical circuit". Your source code describes a logic function description. = Synthesis takes that description as input and produces a bitstream that can= be loaded into a device that will then implement that function. If you cr= eate timing problems that's a design issue (i.e. you described a function t= hat has a design flaw). In many cases, such design issues are beyond the s= cope of the tool. Kevin JenningsArticle: 154027
On Friday, July 13, 2012 12:02:40 PM UTC-4, o pere o wrote: > I can follow this reasoning. However, the result of this should be a=20 > setup or hold time violation signaled by the simulator, shouldn't it?= =20 > But the simulator did NOT show any of them. Instead, a completely bogus= =20 > behavior was observed. Nothing special was reported except the result=20 > being completely wrong. >=20 Simulators don't necessarily catch timing violations. That is the job for = a static timing analysis tool. However, even STA doesn't catch problems wh= en the constraints are not properly defined. In this case, did you tell Qu= artus to ignore clock domain crossings when performing timing analysis? If= I recall correctly, Quartus defaults to this setting and you have to actua= lly tell it to perform the cross clock domain timing analysis. In short, there are a lot more requirements that need to be defined correct= ly in order for static timing analysis to be correctly performed (and no go= od way to validate that you have really got those requirement correctly spe= cified). But when you do specify all the requirements correctly, the timin= g analysis tool will catch and report the problems. A simulator might get = lucky and catch something, but it will miss far more errors because it is n= ot equipped to simulate function in a manner equivalent to how you perform = static timing analysis. Kevin JenningsArticle: 154028
o pere o <me@somewhere.net> wrote: (snip) > Well, I am now just curious to know what happened to cause this > behavior. Most of us learn much more from errors than from blindly > following the rules. And I already looked at the code (actually I > posted the lines that update de SR) and I also looked at the > synthesized circuit. Nothing special there! If you wrote it in verilog, I might be able to figure it out. My only guess is that there is a glitch on the generated clock. That is, it clocks twice when you think it clocks only once. Simulated clocks can have infinitesimal delay and still clock the FF. Real gates won't be able to do that, at least not infinitesimally. With enough delay, you can get a real glitch that can clock a real FF. Another reason for synchronous logic. The old favorite from asynchronous logic days was generating a counter reset from the output of a ripple counter. In some cases, the reset pulse is too short to reset all the FFs, though that depends on the logic being especially fast and the FFs slow. Usually it won't glitch, but I am not sure it isn't possible. (That is, when the reset is also used to clock the next FF.) (Use a 74L74 FF and 74S00 to generate the (not) reset. Except that I forget which FFs have an active low reset.) -- glenArticle: 154029
KJ <kkjennings@sbcglobal.net> wrote: (snip) > Simulators don't necessarily catch timing violations. > That is the job for a static timing analysis tool. > However, even STA doesn't catch problems when the constraints > are not properly defined. What does it do in the case of internally generated clocks. > In this case, did you tell Quartus to ignore clock domain > crossings when performing timing analysis? If you have multiple clock inputs to the logic, then I might see what it would do for static timing. If you generate a clock internally, then it isn't so obvious. > If I recall correctly, Quartus defaults to this setting > and you have to actually tell it to perform the cross > clock domain timing analysis. -- glenArticle: 154030
o pere o wrote: > > However, I still have some questions on this. If I built my design from, > lets say, discrete components, I might have problems with setup and hold > times at the shift register (SR) input, but I would NEVER EVER get the > results that showed up in the simulation: > > The SR was initially cleared. The serial input to the SR is zero at the > first clock but, surprisingly, a one appears at the 9th (!!) SR output > after the first edge of the clock. Can anybody find a plausible > explanation for this? > In FPGA hardware, easily! Xilinx guarantees their LUTs to be glitch-free by themselves, but as has been pointed out here before, when multiple LUTs are strung together with routing delays between them, all bets are off. Can't say about glitch behavior on Altera, but I suspect similar things. Then, the tools pack logic into the LUTs as they fit best, without any attention to making sure glitches can't propagate. Now, why this behavior showed up in simulation is not clear. But, again, if you do things that are really wrong in the HDL, it is possible the simulator just fouls up. > The second question is, is there a way to tell Quartus that it should > synthesize something that resembles the physical circuit? I did tell > Quartus that s_sample was a clock (and told the frequency), however this > was obviously not sufficient. Any thoughts? To some extent, but it reveals you are trying to do something that is bending the tools and FPGA in a way they were not designed for, and will usually lead to trouble. Some people do special things in very special cases such as all-silicon ring oscillators where they are using special knowledge of the internal workings to do what the tools can't handle, but they then have to test the results carefully. It is far better to describe in the HDL the behavior you want and let the tools fit that onto the chip's internal architecture. JonArticle: 154031
Jon Elson <jmelson@wustl.edu> wrote: (snip) >> However, I still have some questions on this. If I built my design from, >> lets say, discrete components, I might have problems with setup and hold >> times at the shift register (SR) input, but I would NEVER EVER get the >> results that showed up in the simulation: I am not so sure about that. (snip) > In FPGA hardware, easily! Xilinx guarantees their LUTs to be glitch-free > by themselves, but as has been pointed out here before, when multiple > LUTs are strung together with routing delays between them, all bets are > off. Can't say about glitch behavior on Altera, but I suspect similar > things. Then, the tools pack logic into the LUTs as they fit best, > without any attention to making sure glitches can't propagate. If they want to work like gates, then they shouldn't glitch in the case where individual gates won't glitch. I suppose if you use only synchronous design techniques then maybe there are no cases where it matters. As far as I know, FPGAs don't require that. > Now, why this behavior showed up in simulation is not clear. > But, again, if you do things that are really wrong in the HDL, > it is possible the simulator just fouls up. Without seeing it in verilog, I don't see it either. Reasonably likely it would be too fast for an actual FF, which I think means it violates setup and/or hold. -- glenArticle: 154032
I need a delay, lets say 10us. I could use a lot of counters to get it from clk, but there probably is a better solution already built in the chip/kit. And of course what is the signal name I can start dividing down to get that 1/10us. This is quite basic question, so a Lattice forum would be a better place to ask this, but Lattice forums I could find were quite quiet. Is there a better place? I'm having holiday and it rains, so I have time to test programming of the LCMXO2-1200ZE-B-EVN ev kit. But I have not EV kit yet. So it limits what I can do and what I know.Article: 154033
LM wrote: > I need a delay, lets say 10us. I could use a lot of counters to get it from clk, but there probably is a better solution already built in the chip/kit. And of course what is the signal name I can start dividing down to get that 1/10us. > > This is quite basic question, so a Lattice forum would be a better place to ask this, but Lattice forums I could find were quite quiet. Is there a better place? > > I'm having holiday and it rains, so I have time to test programming of the LCMXO2-1200ZE-B-EVN ev kit. But I have not EV kit yet. So it limits what I can do and what I know. > You won't get delays of 10 microseconds without using a clock. The MachXO2 doesn't necessarily need an external clock, but its internal oscillator will not give you a very precise delay. There are probably some simple demo designs shipped with the kit that can help you generate a delay. Perhaps you can do it with the Timer/Counter core instead of using the fabric to build counters. -- GaborArticle: 154034
On Tuesday, July 17, 2012 4:33:45 PM UTC+3, Gabor wrote: > LM wrote: > > I need a delay, lets say 10us. I could use a lot of counters to get it from clk, but there probably is a better solution already built in the chip/kit. And of course what is the signal name I can start dividing down to get that 1/10us. > > > > This is quite basic question, so a Lattice forum would be a better place to ask this, but Lattice forums I could find were quite quiet. Is there a better place? > > > > I'm having holiday and it rains, so I have time to test programming of the LCMXO2-1200ZE-B-EVN ev kit. But I have not EV kit yet. So it limits what I can do and what I know. > > > > You won't get delays of 10 microseconds without using a clock. The > MachXO2 doesn't necessarily need an external clock, but its internal > oscillator will not give you a very precise delay. > I understand, but I would guess it has some dividers for that built in. > There are probably some simple demo designs shipped with the kit > that can help you generate a delay. Perhaps you can do it with > the Timer/Counter core instead of using the fabric to build > counters. > > -- Gabor Probably. I looked at some demo designs for ev kit. They were supposed to be in VHDL, but didn't look like it. What is "Timer/Counter core". Where can I find it. I found the IPexpress in Lattice IDE. It has a counter defined but nothing with clock from internal signal. But so far this is best I can find.Article: 154035
Hi all,
Are there any method to use differential I/O simultaneously?
Firstly, route in_P + in_N pad to pad connects to out_P + out_N.
Secondly, route
IBUFDS ( .I(in_P)
.IB(in_N)
.O (out_put)
);
The purpose to doing this is I need No Delay on first route and then
process "out_put" as normal signal.
Please help.
Thanks!
yickma
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 154036LM wrote: > On Tuesday, July 17, 2012 4:33:45 PM UTC+3, Gabor wrote: >> LM wrote: >> > I need a delay, lets say 10us. I could use a lot of counters to get it from clk, but there probably is a better solution already built in the chip/kit. And of course what is the signal name I can start dividing down to get that 1/10us. >> > >> > This is quite basic question, so a Lattice forum would be a better place to ask this, but Lattice forums I could find were quite quiet. Is there a better place? >> > >> > I'm having holiday and it rains, so I have time to test programming of the LCMXO2-1200ZE-B-EVN ev kit. But I have not EV kit yet. So it limits what I can do and what I know. >> > >> >> You won't get delays of 10 microseconds without using a clock. The >> MachXO2 doesn't necessarily need an external clock, but its internal >> oscillator will not give you a very precise delay. >> > I understand, but I would guess it has some dividers for that built in. > >> There are probably some simple demo designs shipped with the kit >> that can help you generate a delay. Perhaps you can do it with >> the Timer/Counter core instead of using the fabric to build >> counters. >> >> -- Gabor > Probably. I looked at some demo designs for ev kit. They were supposed to be in VHDL, but didn't look like it. > > What is "Timer/Counter core". Where can I find it. I found the IPexpress in Lattice IDE. It has a counter defined but nothing with clock from internal signal. But so far this is best I can find. I would suggest looking at the MachXO2 family data sheet: http://www.latticesemi.com/documents/38834.pdf The Timer/Counter is a "hard" function, and may not be on all versions of the MachXO2 family. All of them have the internal oscillator, though and that does have some flexibility in frequency - the same as for master mode configuration (it's the same oscillator). Still the best bet for timing is usually an external crystal oscillator and I'd be surprised if the eval board doesn't come with one. -- GaborArticle: 154037
>Hi all, > >Are there any method to use differential I/O simultaneously? > >Firstly, route in_P + in_N pad to pad connects to out_P + out_N. > >Secondly, route > > IBUFDS ( .I(in_P) > .IB(in_N) > .O (out_put) > ); > >The purpose to doing this is I need No Delay on first route and then >process "out_put" as normal signal. > >Please help. > >Thanks! > >yickma 1. Looks like a Xilinx device - which one? 2. Simultaneously with each other, or something else? 3. How simultaneously? (In femtoseconds, for instance) --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154038
RCIngham wrote: >> Hi all, >> >> Are there any method to use differential I/O simultaneously? >> >> Firstly, route in_P + in_N pad to pad connects to out_P + out_N. >> >> Secondly, route >> >> IBUFDS ( .I(in_P) >> .IB(in_N) >> .O (out_put) >> ); >> >> The purpose to doing this is I need No Delay on first route and then >> process "out_put" as normal signal. >> >> Please help. >> >> Thanks! >> >> yickma > > 1. Looks like a Xilinx device - which one? > > 2. Simultaneously with each other, or something else? > > 3. How simultaneously? (In femtoseconds, for instance) > > > --------------------------------------- > Posted through http://www.FPGARelated.com Newer Xilinx parts have a IBUFDS_DIFF_OUT primitive which gives access to inverted and non-inverted inputs. Obviously there will be a delay from the pad to the output of the buffer - you can't route through the FPGA with no delay. However the delay to each output should be fairly well matched. Normally the only reason to use the IBUFDS_DIFF_OUT primitive is that you have some unusual connection requirement like using two IDELAY primitives - not because you need an inverted copy of the input. -- GaborArticle: 154039
I've discovered that Synplify no longer requires the use of $readmemh / $re=
admemb to initialize inferred blockRAMs or ROMs. I thought I'd post some e=
xamples of this for my own future reference. You can now use the SystemVer=
ilog-style array initialization. You can do this directly, or by using a m=
ultimensional parameter set in a package file. (Don't forget to check the =
'SystemVerilog' option box in Synplify.) You can also initialize a RAM/ROM=
using a function you define in a generate loop. (You have to use a genera=
te loop because an 'initial' loop is ignored by Synplify.) You could use t=
his, for example, to create a sine/cos lookup table. A few examples below.
/*****************************************************************
* Inferred ROM Initialization Using SysVerilog Array Init
*****************************************************************/
module rom0 (input clk, input [5:0] addr, output [9:0] dout);
reg [7:0] rom [0:63] =3D '{ 1, 3, 5, 7, 9,11,13,15, // init values
0, 2, 4, 6, 8,10,12,14,
3, 6, 9,12,15,18,21,24,
1, 3, 5, 7, 9,11,13,15,
0, 2, 4, 6, 8,10,12,14,
3, 6, 9,12,15,18,21,24,
1, 3, 5, 7, 9,11,13,15,
0, 2, 4, 6, 8,10,12,14};
reg [7:0] raddr;
always@(posedge clk) raddr <=3D addr; // blockROM must have reg. addr
assign dout =3D rom[raddr];
endmodule
/*****************************************************************
* Inferred ROM Initialization Using Array Init (Alternate Syntax)
*****************************************************************/
module rom1 (input clk, input [5:0] addr, output [9:0] dout);
reg [7:0] rom [0:63] =3D '{0:8'h55, 3:8'haa, 13:8'hab, default:0};
reg [7:0] raddr;
always@(posedge clk) raddr <=3D addr; // blockROM must have reg. addr
assign dout =3D rom[raddr];
endmodule
/*****************************************************************
* Inferred ROM Initialization Using Loop
*****************************************************************/
module rom2 (input clk, input [5:0] addr, output [9:0] dout);
// Create initialization array using a generate statement
// (You can't use an 'initial' loop because Synplify ingores those)
logic [7:0] init_array [0:63];
generate
for (genvar i=3D0; i<64; i++)=20
assign init_array[i] =3D i**2; // arbitrary function
endgenerate=20
reg [7:0] rom [0:63] =3D init_array; // Infer ROM
reg [7:0] raddr;
always@(posedge clk) raddr <=3D addr; // blockROM must have reg. addr
assign dout =3D rom[raddr];
endmodule
Article: 154040Hi, Quick question. I want to connect a number of FPGA I/Os to ground without changing my VHDL i.e. via a constraint in the UCF file I have tried a number of things without success: NET GND LOC = "AA14" | IOSTANDARD = LVCMOS25; NET gnd_net LOC = "R8" | IOSTANDARD = LVCMOS25; NET "gnd_net" LOC = "AB14" | IOSTANDARD = LVCMOS25; NET "GND_NET" LOC = "W14" | IOSTANDARD = LVCMOS25; NET "ground" LOC = "Y14" | IOSTANDARD = LVCMOS25; Please tell me there is a way to do this (and then tell me what it is :-) ) Thanks, StevenArticle: 154041
On 19/07/2012 11:38, moogyd@yahoo.co.uk wrote: > Hi, > Quick question. > I want to connect a number of FPGA I/Os to ground without changing my VHDL i.e. via a constraint in the UCF file > > I have tried a number of things without success: > > NET GND LOC = "AA14" | IOSTANDARD = LVCMOS25; > NET gnd_net LOC = "R8" | IOSTANDARD = LVCMOS25; > NET "gnd_net" LOC = "AB14" | IOSTANDARD = LVCMOS25; > NET "GND_NET" LOC = "W14" | IOSTANDARD = LVCMOS25; > NET "ground" LOC = "Y14" | IOSTANDARD = LVCMOS25; > > Please tell me there is a way to do this (and then tell me what it is :-) ) > Thanks, > Steven > I thought someone might have replied by now. The only method I can think of is to put a wrapper around your VHDL code, with the extra ground pins tied to GND, and to synthesise that. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 154042
Mike Perkins wrote: > On 19/07/2012 11:38, moogyd@yahoo.co.uk wrote: >> Hi, >> Quick question. >> I want to connect a number of FPGA I/Os to ground without changing my >> VHDL i.e. via a constraint in the UCF file >> >> I have tried a number of things without success: >> >> NET GND LOC = "AA14" | IOSTANDARD = LVCMOS25; >> NET gnd_net LOC = "R8" | IOSTANDARD = LVCMOS25; >> NET "gnd_net" LOC = "AB14" | IOSTANDARD = LVCMOS25; >> NET "GND_NET" LOC = "W14" | IOSTANDARD = LVCMOS25; >> NET "ground" LOC = "Y14" | IOSTANDARD = LVCMOS25; >> >> Please tell me there is a way to do this (and then tell me what it is :-) At least in earlier versions, I did stuff like that with a separate UCF line for each thing I was trying to do. So, I didn't try to put a LOC and a PULLUP or PULLDOWN on the same line. But, the ground function is a CPLD feature that is not present on FPGAs, isn't that right? JonArticle: 154043
moogyd@yahoo.co.uk wrote: > Hi, > Quick question. > I want to connect a number of FPGA I/Os to ground without changing my VHDL i.e. via a constraint in the UCF file > > I have tried a number of things without success: > > NET GND LOC = "AA14" | IOSTANDARD = LVCMOS25; > NET gnd_net LOC = "R8" | IOSTANDARD = LVCMOS25; > NET "gnd_net" LOC = "AB14" | IOSTANDARD = LVCMOS25; > NET "GND_NET" LOC = "W14" | IOSTANDARD = LVCMOS25; > NET "ground" LOC = "Y14" | IOSTANDARD = LVCMOS25; > > Please tell me there is a way to do this (and then tell me what it is :-) ) > Thanks, > Steven > You can't infer drivers from the .ucf file. If you want the gounded pins to act as "virtual grounds" to reduce ground bounce, then you need to add them to your design and assign them to zero. If you really can't change the VHDL for some reason, then you can achieve the same thing using the FPGA editor, but that method is more painful. Just out of curiosity, why don't you want to change the VHDL code? -- GaborArticle: 154044
I'm looking for a FPGA board that can support HDMI/DVI 1080P in/out. I'd like to avoid building my own, I'm probably looking at a volume of 100 units. Any thoughts/suggestions? Thanks! John PArticle: 154045
On Thursday, July 19, 2012 9:34:48 PM UTC+2, Gabor wrote: > m.....@yahoo.co.uk wrote: > > Hi, > > Quick question. > > I want to connect a number of FPGA I/Os to ground without changing my VHDL i.e. via a constraint in the UCF file > > > > I have tried a number of things without success: > > > > NET GND LOC = "AA14" | IOSTANDARD = LVCMOS25; > > NET gnd_net LOC = "R8" | IOSTANDARD = LVCMOS25; > > NET "gnd_net" LOC = "AB14" | IOSTANDARD = LVCMOS25; > > NET "GND_NET" LOC = "W14" | IOSTANDARD = LVCMOS25; > > NET "ground" LOC = "Y14" | IOSTANDARD = LVCMOS25; > > > > Please tell me there is a way to do this (and then tell me what it is :-) ) > > Thanks, > > Steven > > > > You can't infer drivers from the .ucf file. If you want the gounded > pins to act as "virtual grounds" to reduce ground bounce, then you > need to add them to your design and assign them to zero. > > If you really can't change the VHDL for some reason, then you can > achieve the same thing using the FPGA editor, but that method is more > painful. > > Just out of curiosity, why don't you want to change the VHDL code? > > -- Gabor Hi All, I am using an FPGA evaluation board to prototype and ASIC, and I want to avoid (or at least minimize) changes to the RTL between ASIC and FPGA. I was assuming that you could achieve what I wanted via UCF, but it looks like I was wrong :-( Anyway, updates to VHDL it is. Thanks, StevenArticle: 154046
Am Freitag, 20. Juli 2012 04:08:50 UTC+2 schrieb johnp: > I'm looking for a FPGA board that can support HDMI/DVI 1080P in/out. > > I'd like to avoid building my own, I'm probably looking at a volume of 100 units. > > Any thoughts/suggestions? > > Thanks! > > John P Hi John, the Digilent ATLYS has HDMI IN and OUT on separate connectors. It uses a Xilinx Spartan6 Device, so I think it should be capable of handling the datarate needed for 1080p resolution. But take a look at the board documentation first if there may be other limiting factors. Have a nice synthesis EilertArticle: 154047
I know this is a complex issue and that tool providers won't talk loud about it, but Im trying to find effective tools (and their cost) without having to call the providers and having them constantly knock on my door to apply pressure on the selection process. I know of the standard Xilinx/Altera tools, and a few others, but I have no overview, especially not when it comes to prices (once and recurring). I guess the prices will be relative high because of the low volumes of this kind of sw, so Im not scared about that if it can speed up development. I do NOT like cost reducing limitations in tools so they are not really an alternative. I am however interested in different programming languages, even non-traditional. I will be using FPGA's only.. No ASIC.. Any opinions anyone? ThanksArticle: 154048
moogyd@yahoo.co.uk wrote: > On Thursday, July 19, 2012 9:34:48 PM UTC+2, Gabor wrote: >> m.....@yahoo.co.uk wrote: >> > Hi, >> > Quick question. >> > I want to connect a number of FPGA I/Os to ground without changing my VHDL i.e. via a constraint in the UCF file >> > >> > I have tried a number of things without success: >> > >> > NET GND LOC = "AA14" | IOSTANDARD = LVCMOS25; >> > NET gnd_net LOC = "R8" | IOSTANDARD = LVCMOS25; >> > NET "gnd_net" LOC = "AB14" | IOSTANDARD = LVCMOS25; >> > NET "GND_NET" LOC = "W14" | IOSTANDARD = LVCMOS25; >> > NET "ground" LOC = "Y14" | IOSTANDARD = LVCMOS25; >> > >> > Please tell me there is a way to do this (and then tell me what it is :-) ) >> > Thanks, >> > Steven >> > >> >> You can't infer drivers from the .ucf file. If you want the gounded >> pins to act as "virtual grounds" to reduce ground bounce, then you >> need to add them to your design and assign them to zero. >> >> If you really can't change the VHDL for some reason, then you can >> achieve the same thing using the FPGA editor, but that method is more >> painful. >> >> Just out of curiosity, why don't you want to change the VHDL code? >> >> -- Gabor > > Hi All, > I am using an FPGA evaluation board to prototype and ASIC, and I want to avoid (or at least minimize) changes to the RTL between ASIC and FPGA. > > I was assuming that you could achieve what I wanted via UCF, but it looks like I was wrong :-( > > Anyway, updates to VHDL it is. > > Thanks, > Steven Probably the easiest way to avoid changes from the ASIC version is to make a wrapper for the FPGA version that mostly instantiates and hooks up the existing ASIC design, and adds any FPGA-only infrastructure like virtual grounds, internal power-on resets, etc. If I were doing this in Verilog, I'd probably use the preprocessor to ifdef the FPGA additions, but the wrapper works in any HDL. -- GaborArticle: 154049
Morten Leikvoll wrote: > I know this is a complex issue and that tool providers won't talk loud > about it, but Im trying to find effective tools (and their cost) without > having to call the providers and having them constantly knock on my door > to apply pressure on the selection process. > > I know of the standard Xilinx/Altera tools, and a few others, but I have > no overview, especially not when it comes to prices (once and recurring). > I guess the prices will be relative high because of the low volumes of > this kind of sw, so Im not scared about that if it can speed up > development. > > I do NOT like cost reducing limitations in tools so they are not really an > alternative. > I am however interested in different programming languages, even > non-traditional. > I will be using FPGA's only.. No ASIC.. Xilinx has webpack, free, available for MS and Linux systems, 32-bit only (due to export restrictions). It will not handle the very largest FPGAs, but those cost several thousand $ anyway. I am somewhat confused by your question, so I may not have added anything. Jon
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