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
laura_pretty05@yahoo.com.hk wrote: > Jim, > I don't understand what you means. what is Font Rom code? > Laura In your first post, you mentioned a LED display - I assumed 7 Segment as you said 0..F. This needs a lookup table, to convert/map the 4 bit binary, to required LEDs - that table is what I call the Font-Rom. It is missing from the examples you have posted thus far. Have a look at the ISE webpack, WATCHxx.zip examples : these are a 3 digit stopwatch, and they have all you will need. -jgArticle: 98351
Wojtek, It looks like you are using VHDL to program a small PAL part? The error message seems to indicate that the part cannot represent the logic in your equation without first using DeMorgan to generate an active low output. I don't understand why VHDL isn't able to do this for you. The last time I used parts like this I was programming in PALASM. the equation would look like !Y = !A + !B + !C where "+" was the OR operator in PALASM. Maybe your synthesizer wants you to write: not y <= not a or not b or not c; Maybe one of the option settings can allow your synthesizer to do the work for you. Maybe one of the optimization settings? Possibly out of my element here... Good luck, Gabor zlotawy wrote: > Hi, > I learn VHDL. I got text: " > > > > Compiling 'komp.vhd' in 'H:\PROGRAMY\WARP\BIN'. > VHDL parser (h:\programy\warp\bin\vhdlfe.exe V4 IR x66) > Library 'work' => directory 'lc16r4' > Library 'ieee' => directory 'h:\programy\warp\lib\ieee\work' > Using 'h:\programy\warp\lib\ieee\work\stdlogic.vif'. > High-level synthesis (h:\programy\warp\bin\tovif.exe V4 IR x66) > Synthesis and optimization (h:\programy\warp\bin\topld.exe V4 IR x66) > Design optimization (dsgnopt) > Equation minimization (minopt) > Design optimization (dsgnopt) > Device fitting (pla2jed) > Error: Polarity specified for LHS signal y must be Active Low. > " > > Code I was trying to synthes is: > > "library ieee; > use ieee.std_logic_1164.all; > > entity komparator is > port (a,b,c: in std_logic; > y: out std_logic); > end komparator; > > > architecture komparator of komparator is > begin > > yiuyuiku:process(a,b,c) > begin > y <= (a and b and c); > end process; > end komparator;" > > > What is the problem? > > Regards, > WojtekArticle: 98352
fpga_toys@yahoo.com wrote: <snip> > It's with this perspective that domestic FPGA vendors could easily > disappear off the map as quickly as GE, RCA, Magnavox, Packard Bell, > Motorola, and other US TV and Radio suppliers did from 1965 to 1970 > when domestic production pretty much stopped. > > Xilinx doesn't control it's means of production, and with that, it also > does not control it's fate. As FPGAs become a comodity building block > for all electronics, as it seems it will during this decade, then every > major fab on the planet will be producing them ... frequently with the > fabs own design and logo. Since early US patents are set to expire this > decade, that is almost a given. Those same fabs producing FPGAs are > very likely to offer discounted ASIC facilities based on their netlists > ... so I see the structured ASIC market as long term, at all levels. I think FPGAs are a little insulated from the simpler boxes trends, as a substantial portion of the product, is actually software. IIRC, both Altera and Xilinx employ more Engineers on the SW side, than HW, and have done for a while. With Lattice now in the fray, with Fujitsu FAB'd devices, software is going to be the key differentiator. After all, in spite of the best spin efforts from all the marketing departments, the Silicon performances are actually quite similar - expected given they depend mostly on what Process the leading edge FABs can run. -jgArticle: 98353
This is just for impementing un a new technology, i have doubts about how to configure the fpga and how to use the expansion ports, what pins are enabled for I / O, how can i configure them. I have the archive in excel about the pins, what can i choose?Article: 98354
Gary Pearman wrote: > Does anybody know where I can get hold of a cheap Xilinx development > board that has an FPGA with 5v I/O? What size FPGA are you interested in? I make some boards that use the 5 V Spartan FPGAs. One board is for the XCS10 and the other is for the XCS30. Would either of these do you any good? JonArticle: 98355
"Gary Pearman" <g_pearman@hotmail.com> schrieb im Newsbeitrag news:dump21$flh$1@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com... > Does anybody know where I can get hold of a cheap Xilinx development > board that has an FPGA with 5v I/O? Our GOP_XC3S200 Mini FPGA module tolerates input voltages up to 7V at the GAL compatible DIL24 connector. http://www.oho-elektronik.de/index.php?c=1&s=gop_xc3s200 Optionally I/O's drive up to 5V by selectable pullup resistors. These features allows easy interconnection to 5V powered CMOS chips like PIC's, AVR's or others. We use TI's 74CB3T3245 level shifters for this capability. http://focus.ti.com/lit/ds/symlink/sn74cb3t3245.pdf MIKE -- www.oho-elektronik.de OHO-Elektronik Michael Randelzhofer FPGA und CPLD Mini Module Klein aber oho !Article: 98356
Hi,
while i was synthesizing a simple shift register i got an odd behavior.
The device i'm using is a virtex2pro (xc2vp2) the verilog i've used is:
module shift_reg(clk, in , out);
parameter DIM=16;
input clk, rst, in;
output out;
reg [DIM-1:0] SR;
always@(posedge clk)
SR <= {in, SR[DIM-1:1]};
assign out = SR[0];
endmodule
After synthesis xst extracts the shift register and map it to a slice.
The timing report gave a max freq of 341.530MHz.
Then i've tried to resynthesize the module but adding a reset signal to
the SR.
After the synthesis xst didn't found any SR but used 16 FFD and 9
slices. Again the timing report get 1099.505 MHz as max. freqency.
I've obtained same results using synplify pro instead of xst.
Is the last frequency value a right one?
Isn't The Virtex2 maximum clock freq <500MH?
How is it possible that using more slices and flip flops intead of the
LUT configured as SR it gets better performances? Could it be a
synthesizer error?
Thankyou in advances
Giovanni Busonera
Article: 98357
"Alderaan" <giovannibusonera@yahoo.it> wrote in message
news:440f5b18$0$29737$4fafbaef@reader2.news.tin.it...
> Hi,
> while i was synthesizing a simple shift register i got an odd behavior.
> The device i'm using is a virtex2pro (xc2vp2) the verilog i've used is:
>
> module shift_reg(clk, in , out);
> parameter DIM=16;
> input clk, rst, in;
> output out;
>
> reg [DIM-1:0] SR;
>
> always@(posedge clk)
> SR <= {in, SR[DIM-1:1]};
>
> assign out = SR[0];
> endmodule
>
> After synthesis xst extracts the shift register and map it to a slice. The
> timing report gave a max freq of 341.530MHz.
>
> Then i've tried to resynthesize the module but adding a reset signal to
> the SR.
> After the synthesis xst didn't found any SR but used 16 FFD and 9 slices.
> Again the timing report get 1099.505 MHz as max. freqency.
>
> I've obtained same results using synplify pro instead of xst.
>
> Is the last frequency value a right one?
> Isn't The Virtex2 maximum clock freq <500MH?
> How is it possible that using more slices and flip flops intead of the LUT
> configured as SR it gets better performances? Could it be a synthesizer
> error?
>
> Thankyou in advances
> Giovanni Busonera
I can't comment on the reported frequency but the LUT-based SRL does not
support reset. There is no circuitry to change the stored SRL values to a
reset state at the assertion of a reset signal. So, if you want the
contents of the SRL to go to a reset state, you must implement the SRL in
registers (or - more appropriately - the tool should do so for you).
Article: 98358Jim, I know about Menta and ST. ST are countering IBMs 90nm ASIC offering which has been using a licensed 90nm FPGA core from us for over two years now. ST just staying competitive, in my book. Perhaps they saw an opportunity that having a small FPGA core would allow them to address? It appears that the use of the core is restricted to customizing a processor. Not enough details to really see what is being offered. For what, or why. But, if there were any details, then the holders of significant FPGA patent portfolios would probably start to get interested.... At least if you bought the IBM solution you could develop and prototype your solution with Xilinx' proven tools, and be assured that the solution you were getting was from two of the world leaders in their respective fields, and that there would not be any patent disputes that might cause a disruption in supply. The fact that ST dropped their GOSPL FPGA project and went with an (unknown) third party for their offering has puzzled a number of people. We will see. AustinArticle: 98359
John, Interesting opinions. Of course, I disagree that ASICs have any rosy future at all, and I also feel that your conclusion that whoever controls the foundry controls the technology is also quite bizarre. How many patents does Xilinx have? How many are due to expire? How many that are due to expire matter? (All it takes is one of the most recent ones to be a barrier to entry...for the next 20 years). How many lines of code do you need to support your FPGA design (in the tools)? How many hotline engineers does it take to support FPGAs? How do you train and support the distributors, FAEs and customers in a new technology from a new vendor? How much circuit design for FPGAs is done outside the US? Outside silicon valley? How much software for CAD tool support of FPGAs is done elsewhere? Where are the patents being filed? Xilinx doesn't just excell in one area, we excell in as many areas as possible. Each by itself is a huge barrier to entry. Only getting tougher to compete. And, we don't stand still. Did you see the 65nm FPGA announcement last week? http://www.xilinx.com/prs_rls/2006/xil_corp/0630_65nm.htm And, have you heard anything about that 65nm ASIC process being ready for anyone, anywhere? For anything? Other than it is too much money, and too much power? (with no proven IP) Ouch. Where is all that new cool 65nm IP, and stuff for that next killer application? MGTs, MACs, DSP, PPC, etc. Oh, Xilinx has it in their FPGA. AustinArticle: 98360
Jim, I beg to differ. In terms of power, resistance to neutron SEUs, and signal integrity, our silicon has significant advantages. One not so small feature: we have 90nm triple oxide. The process was developed for us, at our request, by two foundries. Oh, and we have it for 65nm, too. Wake up and smell the coffee. We asked for a process, and we had more than one foundry eager to supply it. That sounds to me like a revolution in the fabless model. Instead of "give me your masks and I'll give you some chips" we have a working partnership and cooperation in developing a new process unique to our industry. AustinArticle: 98361
Spartan II's are the last 5V IO tolerant Xilinx FPGA, and their 3.3V outputs are compatible with 5V TTL inputs (0.8 & 2.4V typically). CMOS logic typically has 20% & 80% thresholds, or 1V and 4V respectively. You can safely pull up a spartan 2 output to 5v externally without damaging the fpga. I think Avnet has some cheap dev boards for that family. Andy JonesArticle: 98362
On Wed, 08 Mar 2006 18:51:31 +1100, Allan Herriman <allanherriman@hotmail.com> wrote: >On Tue, 07 Mar 2006 17:01:31 GMT, Duane Clark <dclark@junkmail.com> >wrote: > >>Subhasri krishnan wrote: >>> Hi all, >>> I am trying to modify some code and I came across these constraints. >>> 'clk_in' is the input clock and 'clk' is generated using a DCM (its is >>> the Divide By 2 output). >>> >>> NET "clk_in" TNM_NET = "clk_in"; >>> TIMESPEC "TS_clk_in" = PERIOD "clk_in" 20 ns HIGH 50 %; >>> >>> TIMEGRP "rising_ffs" = RISING "clk"; >>> TIMEGRP "falling_ffs" = FALLING "clk"; >>> TIMESPEC "TS_pos_to_neg" = FROM "rising_ffs" TO "falling_ffs" 5 ns ; >>> >>> Is there something wrong with the last FROM : TO statement? Can the >>> same condition be specified using the Period statement? I think its >>> supposed to mean "delay between the rising and falling edge is to be >>> kept to 5ns". >> >>Yes, the same condition can be specified with a period statement. When >>ISE sees that opposite edges of the clock are being used, it will >>automatically cut the period in half (assuming a HIGH 50 % is >>applicable). So you just need: >>TIMESPEC "TS_clk" = PERIOD "clk" 10 ns HIGH 50 %; > >A period of 20ns and a rising to falling time of 5ns would give a duty >cycle of 25%, not 50%. > >I've never liked the way the duty cycle is specified in UCF, as it's >impossible to describe a worst case range. >For example, if the duty cycle can vary between 40 and 60%, then one >would need to decrease the period spec by 20% to adequately cover the >rising to falling and falling to rising paths, but this results in an >unnecessarily tight spec for the rising to rising and falling to >falling paths. > >Xilinx, take note. > >Regards, >Allan Careful here folks, OP wrote that input clock is "clk_in", and the original UCF says period is 20ns, so 50 MHz. OP wrote that the clock "clk" comes from the DCM div by 2 output, so it will be 25 MHz, with a period of 40ns, not 100 MHz and 10ns. So, the original UCF has a real problem with "TS_pos_to_neg" spec, as it logically should be 20ns for a half cycle, not 5ns. The correct period spec for "clk" would be: TIMESPEC "TS_clk" = PERIOD "clk" 40 ns HIGH 50 %; Alternatively, the from-to spec could be: TIMESPEC "TS_pos_to_neg" = FROM "rising_ffs" TO "falling_ffs" 20 ns ; Alan's comment: >>A period of 20ns and a rising to falling time of 5ns would give a duty >>cycle of 25%, not 50%. is not correct, as he missed that the 20ns was the "clk_in" net, but the 5ns spec was for ffs in the rising/falling subsets of the "clk" net. Given that the "clk" clock is at 25MHz, the 5ns is actually just 12% of the cycle time. Even worse. For Alan's non-symetric duty cycle worst case scenario, I handle it this way (let's stick with 40ns cycle time): TIMEGRP "rising_ffs" = RISING "clk"; TIMEGRP "falling_ffs" = FALLING "clk"; TIMESPEC "TS_pos_to_neg" = FROM "rising_ffs" TO "falling_ffs" 16 ns ; TIMESPEC "TS_neg_to_pos" = FROM "falling_ffs" TO "rising_ffs" 16 ns ; TIMESPEC "TS_pos_to_pos" = FROM "rising_ffs" TO "rising_ffs" 40 ns ; TIMESPEC "TS_neg_to_neg" = FROM "falling_ffs" TO "falling_ffs" 40 ns ; This supports the duty cycle ranging from 40% to 60%, while still giving the full cycles paths a whole cycle. If you actually looked at my UCF files, you would find that I would probably have set the "16 ns" to 15, and the "40 ns" to 38, just so there was a little safety margin for clock jitter, etc. Philip Freidin Philip Freidin FliptronicsArticle: 98363
Greetings! Has anyone got machine readable, hence, net-transferable, documentation for the Insight Spartan-II demo board with the XILINX XC2S100 and 18V01 boot prom? I've managed to become separated from some of the doc's.I have the schematics and the user manual, but the apendices for the user manual seem to have wandered away. I'd like to use this board for something useful, but that's difficult without complete doc's. thanks, RichardArticle: 98364
Austin Lesea wrote: > How many that are due to expire matter? (All it takes is one of the most > recent ones to be a barrier to entry...for the next 20 years). All it takes is demonstrated prior art to avoid it as well, plus some litigation to avoid the challenges. By 1989 what was published regarding FPGAs, and the devices that were in production at that time, provide an architectural wealth for producing patent free comodity FPGA devices, which scaled to current processes, would make a strong competitor for main stream FPGAs. The market for advanced FPGAs would at that time not be nearly as high margin with the cash cows slaughtered, and the competition would become stiff.Article: 98365
This is probably a dumb question, but I'm trying to figure some aspects of the software (ISE 7.1.4) out. I have a design for a Virtex-II FPGA that basically consists of several data busses and several accumulators (Xilinx Core) which correspond to the data busses, and some control signals. Basically I'm taking data in and either adding it to or substracting it from the accumulators. At this point it's a really simple case where I'm using 1-bit as a control signal. '1' I add, '0' I substract. Both the control signal and the data are clocked in by seperate clock signals. Real simple. The sequence goes: Control signal valid -> control clock edge -> data valid -> data strobe Speed is about 5 MHz overall with the signal, clock, signal, clock sequence basically evenly spaced over that period. If I basically leave the tools to their own (Xilinx ISE 7.1) what it basically does is put a flip-flop near the control signal and clock and fans the output out to the accumulators... Which amounts to something like 164 internal signals. The auto-routing of the internal signals ends up as a mess that basically doesn't work. I can fix it by going into the placement editor and moving the flip-flop to a logical place near the accumulators so the router ends up with a more reasonable route. Which is okay, I guess. My question is how do I specify timing contraints such that the placement minimizes the route from the output of the flip-flop to the accumulators? The other thing I can do is replicate the flip-flop for the control signal for each accumulator and set ISE to not trim duplicated registers... Thanks!Article: 98366
To clarify, the flip-flop is placed near the PAD for the control signal by the ISE software. The out put is then routed to all the accumulators.Article: 98367
On Wed, 08 Mar 2006 23:30:47 +0100, Alderaan <giovannibusonera@yahoo.it> wrote: >Then i've tried to resynthesize the module but adding a reset signal to >the SR. >After the synthesis xst didn't found any SR but used 16 FFD and 9 >slices. Again the timing report get 1099.505 MHz as max. freqency. > >I've obtained same results using synplify pro instead of xst. > >Is the last frequency value a right one? >Isn't The Virtex2 maximum clock freq <500MH? >How is it possible that using more slices and flip flops intead of the >LUT configured as SR it gets better performances? Could it be a >synthesizer error? The LUT as shift register application is not optimized for timing and it doesn't support reset or when you add the reset you get the actual flops. If these flops are placed nicely, ie with minimal routing delay the minimum period is decided by the equation Tclk2Q + Tsetup (assuming no-clock tree skew) so it's reasonable to get a number around 1ns for this. The reported register to lut to register performance of a -6 device is 1046 MHz.Article: 98368
A more intersting discussion for me is the best path for converting
expensive high end FPGA designs into ASICs. I viewed rapidchip as one of
these paths- so what's left? Is this even a big business?
Xilinx: easypath - lower cost but no faster.
Altera: hardcopy-II - these are structured ASICs. They look appealing, but
I did not get the impression that there were many conversions (at least as
of a year ago).
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 98369
just add a signal
signal clk_counter : std_logic;
change the clock of your counter
c1: counter port map (clock=>clk_counter , reset=>PB1, count=> count);
and make a process to change the clock of you counter
process(count)
begin
if count = 10 or count=11 or count=12 or count=13 or count=14 or count=15
then
clk_counter <= clk_25MHz;
else
clk_counter <= clock_1Hz ;
end if;
end process;
like this it will count 1 digit each second when betwen 0 to 9 and count so
fast that no one will notice anything betwen 10 to 15
Regards
kcl
<laura_pretty05@yahoo.com.hk> wrote in message
news:1141816072.606433.278480@j52g2000cwj.googlegroups.com...
hi, Aurelian Lazarut
I still don't understand what you means. How to decode in VHDL?
The following are my counter VHDL code:
Library IEEE;
USE IEEE.std_logic_1164.all;
USE IEEE.std_logic_arith.all;
USE IEEE.std_logic_unsigned.all;
Entity Counter IS
Port
( Clock, Reset :IN std_logic;
count : OUT std_logic_vector(3 DOWNTO 0));
END Counter;
ARCHITECTURE a OF Counter IS
SIGNAL internal_count: std_logic_vector(3 DOWNTO 0);
BEGIN
count <= internal_count;
Process (Reset, Clock)
BEGIN
IF Reset='0' THEN
internal_count <= "0000";
ELSIF (Clock'EVENT AND clock='1') THEN
internal_count <= internal_count + 1;
END IF;
END Process;
END a;
from Laura
Aurelian Lazarut ??:
> sandypure@yahoo.com wrote:
> > I have implemented a 8-bit synchronous counter by VHDL.
>
> I'll give you a hint, the counter is not in this file, only the
> intantiation of the counter.
> but you can decode count=10 and trigger a reset. (in this file)
> as Alan just said.
>
> Aurash
>
> The result is
> > that the LED display show continuously running the count from 0 to
> > F(in Hex). Now, I need to change the result which the LED display can
> > count from 0 to 9 only. How can I change in the VHDL code? Can anyone
> > answer me? Thanks a lot!!
> > The following VHDL code are about 8-bit synchronous counter:
> > Library IEEE;
> > USE IEEE.std_logic_1164.all;
> > USE IEEE.std_logic_arith.all;
> > USE IEEE.std_logic_unsigned.all;
> >
> > ENTITY counter_eg IS
> > PORT(
> > PB1, clk_25MHz : IN std_logic;
> > led0, led1, led2, led3, led4, led5, led6 : OUT std_logic);
> > END counter_eg;
> >
> > ARCHITECTURE c OF counter_eg IS
> >
> > COMPONENT counter
> > PORT(
> > Clock, Reset : IN std_logic;
> > count : OUT std_logic_vector(3 DOWNTO 0));
> >
> > END COMPONENT;
> >
> > COMPONENT dec_7seg
> > PORT(
> > hex_digit : IN std_logic_vector(3 DOWNTO 0);
> > segment_a, segment_b, segment_c, segment_d, segment_e,
> > segment_f, segment_g : OUT std_logic);
> > END COMPONENT;
> >
> > COMPONENT clk_div
> > PORT(
> > clock_25MHz : IN std_logic;
> > clock_1MHz : OUT std_logic;
> > clock_100KHz : OUT std_logic;
> > clock_10KHz : OUT std_logic;
> > clock_1KHz : OUT std_logic;
> > clock_100Hz : OUT std_logic;
> > clock_10Hz : OUT std_logic;
> > clock_1Hz : OUT std_logic);
> > END COMPONENT;
> >
> > SIGNAL count : std_logic_vector(3 DOWNTO 0);
> > SIGNAL clk_1KHz : std_logic;
> > BEGIN
> > c0: clk_div port map (clock_25MHz=> clk_25MHz, clock_1KHz=>clk_1KHz);
> > c1: counter port map (clock=>clk_1KHz, reset=>PB1, count=> count);
> > c2: dec_7seg port map (count, led0, led1, led2, led3, led4, led5,
> > led6);
> >
> > END c;
> >
Article: 98370A coworker asked me if I knew of a problem with synthesis tools inferring RAM (Xilinx is the target) from an array of records, versus an array of std_[u]logic_vector. He was using XST; I haven't had a chance to try Synplify or Precision. Is anyone aware of specific limitations along this line? Or which tools support this coding construct? JTWArticle: 98371
Volumes and TTM (time to market) will dictate the path you take, either ASIC
or structure ASIC. And sometimes they both can work for you. We have a
recent product with projected numbers that make an ASIC the best candidate,
lowest UMC. The downside is that the ASIC has a long schedule; so long that
we would miss launch: missing the market with a product can cost a company
big $$. The answer, launch with a structure ASIC (Altera HC) and roll in
the full ASIC later in production. Yes, you get nailed with 2 NRE's, but if
your numbers are high enough (as they are in our case) the business case can
make sense.
In our case the ASIC was a little less than half the cost of the Structured
ASIC. Altera's HC also can afford you a pin compatible footprint such that
you can plop an FPGA down on your production board if you wanted to do
further development.
"Joseph H Allen" <jhallen@TheWorld.com> wrote in message
news:duo67n$4ml$1@pcls4.std.com...
>A more intersting discussion for me is the best path for converting
> expensive high end FPGA designs into ASICs. I viewed rapidchip as one of
> these paths- so what's left? Is this even a big business?
>
> Xilinx: easypath - lower cost but no faster.
>
> Altera: hardcopy-II - these are structured ASICs. They look appealing,
> but
> I did not get the impression that there were many conversions (at least as
> of a year ago).
>
> --
> /* jhallen@world.std.com (192.74.137.5) */ /* Joseph H.
> Allen */
> int
> a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
> +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
> ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n","
> #"[!a[q-1]]);}
Article: 98372On Thu, 09 Mar 2006 00:17:27 GMT, Philip Freidin <philip@fliptronics.com> wrote: >On Wed, 08 Mar 2006 18:51:31 +1100, Allan Herriman <allanherriman@hotmail.com> wrote: >>On Tue, 07 Mar 2006 17:01:31 GMT, Duane Clark <dclark@junkmail.com> >>wrote: >> >>>Subhasri krishnan wrote: >>>> Hi all, >>>> I am trying to modify some code and I came across these constraints. >>>> 'clk_in' is the input clock and 'clk' is generated using a DCM (its is >>>> the Divide By 2 output). >>>> >>>> NET "clk_in" TNM_NET = "clk_in"; >>>> TIMESPEC "TS_clk_in" = PERIOD "clk_in" 20 ns HIGH 50 %; >>>> >>>> TIMEGRP "rising_ffs" = RISING "clk"; >>>> TIMEGRP "falling_ffs" = FALLING "clk"; >>>> TIMESPEC "TS_pos_to_neg" = FROM "rising_ffs" TO "falling_ffs" 5 ns ; >>>> >>>> Is there something wrong with the last FROM : TO statement? Can the >>>> same condition be specified using the Period statement? I think its >>>> supposed to mean "delay between the rising and falling edge is to be >>>> kept to 5ns". >>> >>>Yes, the same condition can be specified with a period statement. When >>>ISE sees that opposite edges of the clock are being used, it will >>>automatically cut the period in half (assuming a HIGH 50 % is >>>applicable). So you just need: >>>TIMESPEC "TS_clk" = PERIOD "clk" 10 ns HIGH 50 %; >> >>A period of 20ns and a rising to falling time of 5ns would give a duty >>cycle of 25%, not 50%. >> >>I've never liked the way the duty cycle is specified in UCF, as it's >>impossible to describe a worst case range. >>For example, if the duty cycle can vary between 40 and 60%, then one >>would need to decrease the period spec by 20% to adequately cover the >>rising to falling and falling to rising paths, but this results in an >>unnecessarily tight spec for the rising to rising and falling to >>falling paths. >> >>Xilinx, take note. >> >>Regards, >>Allan > > >Careful here folks, > >OP wrote that input clock is "clk_in", and the original UCF says period >is 20ns, so 50 MHz. > >OP wrote that the clock "clk" comes from the DCM div by 2 output, so >it will be 25 MHz, with a period of 40ns, not 100 MHz and 10ns. > >So, the original UCF has a real problem with "TS_pos_to_neg" spec, as >it logically should be 20ns for a half cycle, not 5ns. > >The correct period spec for "clk" would be: > > TIMESPEC "TS_clk" = PERIOD "clk" 40 ns HIGH 50 %; > >Alternatively, the from-to spec could be: > >TIMESPEC "TS_pos_to_neg" = FROM "rising_ffs" TO "falling_ffs" 20 ns ; > >Alan's comment: >>>A period of 20ns and a rising to falling time of 5ns would give a duty >>>cycle of 25%, not 50%. > >is not correct, as he missed that the 20ns was the "clk_in" net, but the >5ns spec was for ffs in the rising/falling subsets of the "clk" net. >Given that the "clk" clock is at 25MHz, the 5ns is actually just 12% >of the cycle time. Even worse. > >For Alan's non-symetric duty cycle worst case scenario, I handle it >this way (let's stick with 40ns cycle time): > >TIMEGRP "rising_ffs" = RISING "clk"; >TIMEGRP "falling_ffs" = FALLING "clk"; >TIMESPEC "TS_pos_to_neg" = FROM "rising_ffs" TO "falling_ffs" 16 ns ; >TIMESPEC "TS_neg_to_pos" = FROM "falling_ffs" TO "rising_ffs" 16 ns ; >TIMESPEC "TS_pos_to_pos" = FROM "rising_ffs" TO "rising_ffs" 40 ns ; >TIMESPEC "TS_neg_to_neg" = FROM "falling_ffs" TO "falling_ffs" 40 ns ; > >This supports the duty cycle ranging from 40% to 60%, while still >giving the full cycles paths a whole cycle. > >If you actually looked at my UCF files, you would find that I would >probably have set the "16 ns" to 15, and the "40 ns" to 38, just so there >was a little safety margin for clock jitter, etc. Yes, that's what I do to. My apologies for missing the fact that a DCM divide by 2 output was used. AllanArticle: 98373
I'm facing an issue using TextIO in initialising a ROM block in my
design...
Here's the code snippet with the issue ::
<SNIP>
architecture Behavioral of roms2 is
type rom_mem_type is array (0 to 31) of std_logic_vector (15 downto
0);
FILE rom_file_ptr : TEXT open READ_MODE is "E:/roms.txt";
impure function rom_function(temp : in string) return rom_mem_type
is
variable line_buffer : LINE ;
variable count: integer := 0;
variable word: bit_vector(1 to 16);
variable rom_word_buffer : std_logic_vector(15 downto 0);
variable rom_buffer : rom_mem_type;
begin
for I in rom_mem_type'range loop
readline (rom_file_ptr, line_buffer);
exit when endfile (rom_file_ptr);
read (line_buffer, word);
-- exit when endfile (rom_file_ptr);
rom_buffer(I) := to_stdlogicvector(word);
end loop;
return rom_buffer;
end function;
signal rom_mem : rom_mem_type := rom_function("") ;
</SNIP>
Answer record on ::
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=22376
does'nt seem to help with this either... The problem just does'nt go
away..
Has anyone figured a way around this ?
Xilinx people pl. help (!)
Article: 98374jhallen@TheWorld.com (Joseph H Allen) writes: > A more intersting discussion for me is the best path for converting > expensive high end FPGA designs into ASICs. I viewed rapidchip as one of > these paths- so what's left? Is this even a big business? NEC has a structured ASIC family (like the ISSP90). Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
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