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
Hi all,
I have designed a fsm to check whether data on three signal buses: y,
u and v (camera data) are in a certain given range. I can't understand
why ise9.2i shows following warnings:
WARNING:Xst:1710 - FF/Latch <yuv_comp_0> (without init value) has a
constant value of 0 in block <color_recognition>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<yuv_comp_1> (without init value) has a constant value of 0 in block
<color_recognition>.
These warnings come up when I synthesize this module as a component of
some other module which gives inputs to it.
The simulation in modelsim works perfectly.
When I synthesize this module only, independently ,i.e without
instantiating it as component of other module; these warnings do not
come up.
Here is the part of the code: (I have used three process model for
fsm. )
--yuv_comp is a 3-bit register.
--some concurrent assignments:
compared <= yuv_comp(2) and yuv_comp(1) and yuv_comp(0);
--y_is_inrange <= .............. here comparision is made with input
signals.
--similar assignments for u_is_inrange and v_is_inrange
--this is a part of combinational process for state transition, there
are default assignments to
-avoid latch. Then:
case pstate is
when idle =>
if (new_frame = '1') then
nstate <= update_output;
end if;
when update_output =>
nstate <= wait_linestart;
when wait_linestart =>
pixel_count_clear <= '1';
if (new_frame = '0') then
nstate <= for_u;
end if;
when for_u =>
if (new_frame = '1') then
nstate <= update_output;
elsif (data_valid_in = '1') then
nstate <= for_v;
end if;
when for_v =>
if (new_frame = '1') then
nstate <= update_output;
elsif (data_valid_in = '1') then
nstate <= decision;
end if;
when decision =>
if (compared = '1') then
pixel_count_en <= '1';
end if;
if (new_frame = '1') then
nstate <= update_output;
else
nstate <= for_u;
end if;
when others =>
nstate <= idle;
end case;
-- end of process for combin.
reg_out: process(clk, reset) is
begin
if rising_edge(clk) then
case pstate is
when idle =>
yuv_comp(2 downto 0) <= "000";
when update_output =>
total_pixels_in_range <= total_pixel_count;
when for_u =>
if(data_valid_in = '1') then
yuv_comp(2) <= y_is_inrange;
yuv_comp(1) <= u_is_inrange;
end if;
when for_v =>
if (data_valid_in = '1') then
yuv_comp(0) <= v_is_inrange;
end if;
when decision =>
null;
when others =>
null;
end case;
end if;
Here is some part of synthesis report which seems to be ok except of
course the warnings mentioned above:
Found finite state machine <FSM_2> for signal <pstate>.
-----------------------------------------------------------------------
| States |
6 |
| Transitions |
13 |
| Inputs |
2 |
| Outputs |
6 |
| Clock | clk
(rising_edge) |
| Reset | reset
(positive) |
| Reset type |
asynchronous |
| Reset State |
idle |
| Power Up State |
idle |
| Encoding |
automatic |
| Implementation |
LUT |
-----------------------------------------------------------------------
Found 16-bit register for signal <total_pixels_in_range>.
Found 16-bit up counter for signal <total_pixel_count>.
Found 8-bit comparator greater for signal <u_is_inrange
$cmp_gt0000> created at line 87.
Found 8-bit comparator less for signal <u_is_inrange$cmp_lt0000>
created at line 87.
Found 8-bit comparator greater for signal <v_is_inrange
$cmp_gt0000> created at line 90.
Found 8-bit comparator less for signal <v_is_inrange$cmp_lt0000>
created at line 90.
Found 8-bit comparator greater for signal <y_is_inrange
$cmp_gt0000> created at line 84.
Found 8-bit comparator less for signal <y_is_inrange$cmp_lt0000>
created at line 84.
Found 3-bit register for signal <yuv_comp>.
Summary:
inferred 1 Finite State Machine(s).
inferred 1 Counter(s).
inferred 19 D-type flip-flop(s).
inferred 6 Comparator(s).
* Advanced HDL
Synthesis *
=========================================================================
Analyzing FSM <FSM_2> for best encoding.
Optimizing FSM <color1_recognize/pstate> on signal <pstate[1:3]> with
gray encoding.
Optimizing FSM <color2_recognize/pstate> on signal <pstate[1:3]> with
gray encoding.
Optimizing FSM <color3_recognize/pstate> on signal <pstate[1:3]> with
gray encoding.
----------------------------
State | Encoding
----------------------------
idle | 000
wait_linestart | 011
update_output | 001
for_u | 010
for_v | 110
decision | 111
----------------------------
Article: 138751Hello. Why is there such a difference in occupied slices between single and dual port RAM both same size? 16k x 1bit Single port 102% on Spartan 3 XC3S400 16k x 1bit Dual port (only dual read) is 69% Why dual port consumes so much more logic? I thought it will be a little more or on the other hand, twice more.. If someone could explain from where comes the 33% difference. BTW: I know I can use block ram, that is not the question :) Thank U !Article: 138752
Another question Why dual port RAM with two inputs (write for both address inputs on the same clock) can not be synthesized? I know it won't use block RAM.Article: 138753
On Mar 8, 12:38=A0pm, "Mad I.D." <madi...@gmail.com> wrote: > Another question > > Why dual port RAM with two inputs (write for both address inputs on > the same clock) > =A0can not be synthesized? I know it won't use block RAM. BlockRAM is inherently dual-ported, so the second port is there for free. Distributed LUT-RAM is inherently single-ported, so the second port must be provided by a second LUT. Peter AlfkeArticle: 138754
In article <317f5ab5-03f3-4445-9cc5-fbd30d47da41@e15g2000vbe.googlegroups.com>,
Mad I.D. <madid87@gmail.com> wrote:
>Another question
>
>Why dual port RAM with two inputs (write for both address inputs on
>the same clock)
> can not be synthesized? I know it won't use block RAM.
Are you doing an explicit priority encode for which data ends up in
the RAM when the two writes are to the same address? Otherwise it
seems that it will end up with sufficiently many undefined behaviours
that I could see it being unsynthesisable.
How are you writing your RAMs? I would be very surprised if you couldn't
synthesise something written like
always @(posedge clock) begin
for (i=0; i<1024; i=1+i) begin
if (address1 == i) then begin
ram[8*i:8*i+7]=input1[0:7]
end
else begin
if (address2 == i) then begin
ram[8*i:8*i+7]=input2[0:7]
end
end
end
end
though it would end up larger than something quite large
Tom
Article: 138755Hi, I am presently working on Writing Test cases and Test benches. I have a general query which makes me confusion. I have a FPGA clock: fpga_clk = 50 MHz and its duty cycle = 50%, here is description; I am writing a one word data into the register and it will store in some address after that it will start transmit using format Manchester, and where my output is rcom_tx will get assert high..this is the process. If i changed my duty cycle to 40% and 60% than what can i expect on my output does it assert high or low or tri-states. Please give me some exposure on this confusion, and suggestions. J.Sreeni, Moog India Technology Center(Moog,Inc-USA)Article: 138756
rickman wrote: > of the 3.3 volt standard going away any time soon. So over the next > five years, any FPGA aimed at the general logic market will pretty > much *have* to support 3.3 volts. As the feature sizes shrink we hear > that (at least in the case of Xilinx) it becomes prohibitively > expensive to continue to support higher voltage I/O standards. The question is what is 3.3v support. For example in CycloneIII the 3.3v IO is almost unusable for any fast signal, the maximum drive strength is so low. Fortunately if 3.0v is used the drive strength is better, and 3.0v should be compatible enough with 3.3v standards. --KimArticle: 138757
On 9 Mrz., 05:28, JSreeniv <sreenivas.jyo...@gmail.com> wrote: > Hi, > I am presently working on Writing Test cases and Test benches. > I have a general query which makes me confusion. > I have a FPGA clock: fpga_clk = 50 MHz and its duty cycle = 50%, here > is description; > I am writing a one word data into the register and it will store in > some address after that it will start transmit using format > Manchester, and where my output is rcom_tx will get assert high..this > is the process. > > If i changed my duty cycle to 40% and 60% than what can i expect on my > output does it assert high or low or tri-states. > > Please give me some exposure on this confusion, and suggestions. > > J.Sreeni, > Moog India Technology Center(Moog,Inc-USA) Hi, the behavior of your circuit depends on how it is written. So, without any code noone can really say anything useful. Just one hint: If your code is well designed and using only the rising edges of your clock then the clocks duty cycle shouldn't matter at all, at least not in behavioral simulation. Have a nice simulation EilertArticle: 138758
http://www.aipst.com/AIPS7108.pdf http://www.aipst.com/aips7108.tar.gzArticle: 138759
In comp.arch.fpga Kim Enkovaara <kim.enkovaara@iki.fi> wrote: > rickman wrote: > > of the 3.3 volt standard going away any time soon. So over the next > > five years, any FPGA aimed at the general logic market will pretty > > much *have* to support 3.3 volts. As the feature sizes shrink we hear > > that (at least in the case of Xilinx) it becomes prohibitively > > expensive to continue to support higher voltage I/O standards. > The question is what is 3.3v support. For example in CycloneIII the > 3.3v IO is almost unusable for any fast signal, the maximum drive > strength is so low. Fortunately if 3.0v is used the drive strength > is better, and 3.0v should be compatible enough with 3.3v standards. At the cost of an additional voltage. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 138760
Luc wrote: > David, > > I know from experience that - at least in Europe - disti's suck. They > will say of course that the silicon is available. But when it comes to > production, then you might have a problem. > > Luc > My experience with distributors in Norway has mostly varied between good and excellent. I haven't had to push hard for early samples of FPGAs, however, so maybe they are particularly problematic there.Article: 138761
Hi I have some IO that I am routing from a Virtex 5 to a board connector. I need to use the IO as either single ended of differential pairs. Would it be ok to route the signals as though they were single ended even though I would be using them as differential pairs too. I guess the impedance would be not 100 ohmns for the differential pairs but would that be ok? cheers JonArticle: 138762
Hi, I am working on a project where I need to process an image in the FPGA and take input image from and send back output image to the computer. Could someone help regarding how exactly can it be done or a source of information wither webpage, or books? Is it by using parallel port of the Computer, and JTAG port of the FPGA? Or can the IO ports be used?Article: 138763
I am building a design that has to interface with some simple chips outside of my FPGA (I'm using a Virtex II). These chips are configured in a daisy-chain and need to receive a serial bitstream from my design. I am using a DDR register to generate the clock signal at the output pin and the data is being clocked out normally. I had trouble getting the timing to work out right. I was noticing that the chip was getting the bitstream off by one bit, i.e. it simply missed my first data bit and the rest were off by one clock cycle. Looking at the clock and data outputs on a scope identified the problem. Because of the daisy-chain architecture, the data line only has to drive one chip while the clock is driving all the chips. The extra load on the clock caused it to have a longer rise time such that the transition point for latching the receiving FFs occurred after the data stream had switched to its next clock cycle. This basically amounts to a hold time violation since my data did not remain valid long enough at the receiving end. A solution I came up with was to reverse the polarity of the clock at the output. I changed the DDR register so that when the internal clock has a rising edge, the output clock goes low. It seems to work, but I wanted to get a second opinion on my solution. I'm wondering if my original method would have worked in the first place even if there wasn't a significant load on the clock line? Since my clock and data are both being generated by FFs at the outputs, wouldn't the original configuration cause the rising edge of the clock to occur at the same time as the data was changing thereby inviting a whole host of metastability problems?Article: 138764
longbrmb@gmail.com wrote:
> I'm wondering if my original method would have worked in the first
> place even if there wasn't a significant load on the clock line?
It might have worked with the right timing constraints.
STA always reports Fmax for internal registers,
but has no idea about external constraints unless
I tell it.
-- Mike Treseler
Article: 138765On Mar 9, 7:05=A0am, longb...@gmail.com wrote: > I am building a design that has to interface with some simple chips > outside of my FPGA (I'm using a Virtex II). =A0These chips are > configured in a daisy-chain and need to receive a serial bitstream > from my design. =A0I am using a DDR register to generate the clock > signal at the output pin and the data is being clocked out normally. > > I had trouble getting the timing to work out right. =A0I was noticing > that the chip was getting the bitstream off by one bit, i.e. it simply > missed my first data bit and the rest were off by one clock cycle. > Looking at the clock and data outputs on a scope identified the > problem. =A0Because of the daisy-chain architecture, the data line only > has to drive one chip while the clock is driving all the chips. =A0The > extra load on the clock caused it to have a longer rise time such that > the transition point for latching the receiving FFs occurred after the > data stream had switched to its next clock cycle. > > This basically amounts to a hold time violation since my data did not > remain valid long enough at the receiving end. =A0A solution I came up > with was to reverse the polarity of the clock at the output. =A0I > changed the DDR register so that when the internal clock has a rising > edge, the output clock goes low. =A0It seems to work, but I wanted to > get a second opinion on my solution. > > I'm wondering if my original method would have worked in the first > place even if there wasn't a significant load on the clock line? > Since my clock and data are both being generated by FFs at the > outputs, wouldn't the original configuration cause the rising edge of > the clock to occur at the same time as the data was changing thereby > inviting a whole host of metastability problems? Your solution of inverting the clock phase is valid IF you analyze the setup/hold time of the receiving devices. In effect, you put your clock edge right in the middle of the data eye and have provided equal setup/hold times. Is this what the receivers require? John ProvidenzaArticle: 138766
On Mar 9, 10:05=A0am, longb...@gmail.com wrote: > I'm wondering if my original method would have worked in the first > place even if there wasn't a significant load on the clock line? Not reliably, a given board might work, another might not. A 'working' board might stop working, or a 'not working' one might start working after having been powered up for some period of time. > Since my clock and data are both being generated by FFs at the > outputs, wouldn't the original configuration cause the rising edge of > the clock to occur at the same time as the data was changing thereby > inviting a whole host of metastability problems? Yes. The source of a clock signal must be guaranteed to occur before the data that you intend to sample with that clock. By designing both to come out of the same nominal structure in the same fashion (i.e. two FFs that are clocked by the same signal) you can't guarantee that condition will be met. Kevin JenningsArticle: 138767
Two single ended lines of Impedance Z can be used as a differential line of impedance 2*Z if they are of same length and are seperated enough to not interact with each others. As soon as the two lines get closer together the differential impedance will deviate from 2*Z. They can still be used both as single ended and differential lines but will be difficult to terminate for both cases simultaneously. Kolja Sulimma On 9 Mrz., 14:23, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Hi > > I have some IO that I am routing from a Virtex 5 to a board connector. I > need to use the IO as either single ended of differential pairs. Would it > be ok to route the signals as though they were single ended even though I > would be using them as differential pairs too. I guess the impedance would > be not 100 ohmns for the differential pairs but would that be ok?Article: 138768
On Mar 9, 11:54=A0am, KJ <kkjenni...@sbcglobal.net> wrote: > The source of a clock signal must be guaranteed to occur before the > data that you intend to sample with that clock. =A0By designing both to > come out of the same nominal structure in the same fashion (i.e. two > FFs that are clocked by the same signal) you can't guarantee that > condition will be met. > > Kevin Jennings So if this implementation would cause problems with the timing, am I misunderstanding how the "generate clock with DDR register" idea works? I was under the impression that using the DDR register would provide a source synchronous clock that is properly aligned with your output data stream. I haven't seen any app notes that talk about this in detail, they just mention using a DDR register in passing. Maybe there are some implied timing constraints when people talk about this method and I'm just not aware of them? Matt LongbrakeArticle: 138769
Pritha Ghoshal <ghoshal.pritha@gmail.com> wrote: > I am working on a project where I need to process an image in the FPGA > and take input image from and send back output image to the computer. To really answer this question, one would need to know some details of the alrorithm, but... > Could someone help regarding how exactly can it be done or a source of > information wither webpage, or books? I recommend the systolic array architecture for a variety of FPGA based signal processing algorithms. > Is it by using parallel port of the Computer, and JTAG port of the > FPGA? Or can the IO ports be used? In most cases, the parallel port will be too slow. PCI might be a good choice. There are FPGA based PCI boards available. Do you have to build the hardware or just the HDL code? -- glenArticle: 138770
Ok thanks for the info. >Two single ended lines of Impedance Z can be used as a differential >line of impedance 2*Z >if they are of same length and are seperated enough to not interact >with each others. > >As soon as the two lines get closer together the differential >impedance will deviate from 2*Z. >They can still be used both as single ended and differential lines but >will be difficult to terminate >for both cases simultaneously. > >Kolja Sulimma > >On 9 Mrz., 14:23, "maxascent" <maxasc...@yahoo.co.uk> wrote: >> Hi >> >> I have some IO that I am routing from a Virtex 5 to a board connector. I >> need to use the IO as either single ended of differential pairs. Would it >> be ok to route the signals as though they were single ended even though I >> would be using them as differential pairs too. I guess the impedance would >> be not 100 ohmns for the differential pairs but would that be ok? >Article: 138771
Thanks a lot for your reply. The algorithm will be simple - edge detection and colour conversion or something similar. And I need to mainly do the HDL code. Is some extra hardware crucial, or is it possible to work only with the computer and FPGA kit? PrithaArticle: 138772
On Mar 5, 2:42=A0pm, justforpret...@gmail.com wrote: > I hope this isn't terribly inappropriate to post here. =A0I want to buy > three FPGA-related T-shirts. =A0I know that Altera and Xilinx have in > the past given out freebie shirts, and I'm trying to track some down > as gifts for my roommates, who work with FPGAs. =A0I will pay good money > for them!! > > Let me know if you have something lying around that you don't mind > parting with. =A0They primarily use Altera, so that's preferable. This will be a good test to see if the vendors still monitor this group. I can't imagine that a vendor would not want to reward such loyal customers. I hope that's not laying it on too thick... ;^) RickArticle: 138773
Pritha Ghoshal <ghoshal.pritha@gmail.com> wrote: > The algorithm will be simple - edge detection and colour > conversion or something similar. > And I need to mainly do the HDL code. Is some extra hardware crucial, > or is it possible to work only with the computer and FPGA kit? For the problems I am used to, speed is very important. If you just need to demonstrate a working algorithm, a parallel port might be fine. The systolic array architecture (see Systolic_array in wikipedia) is very different from the usual software implementation. To demonstrate that you understand the algorithm, speed isn't important, though it is usually the reason behind hardware implementations. -- glenArticle: 138774
Hi, I worked on a video processing project not so long ago, and I think I might help here. Our project was an image binarization system based on euler numbers. The design did not have any minimum clock frequency and did the processing on-the- fly requiring only a clock input and an 8-bit pixel data bus (grayscale). We actually implemented two versions of the test unit. 1) We used an 8bit embedded controller programmed in C with a port of a filesystem, to which an SD memory card containing some test binary files was connected. These files were originally generated by matlab. The 8bit embedded controller then read the files sequentially and streamed it to our unit under test (UUT). We achieved a data rate of about 300KBytes with this method. For every frame that was streamed to the UUT, we obtained an 8bit threshold value which was then written back to the SD memory card as a new result file. 2) In the second method, we used a usb device by microchip with the CDC stack. The device that we used was the pic18f2450. We modified the CDC stack which is a free usb to serial converter offered by microchip, to allow us to write parallel data to the controller's port instead of it being serial. We actually kept the serial output line, so the controller was just writing to the UUT in parallel and reading the result, which was an 8bit threshold value, and serially sending it back to the host PC. The nice thing about the second implementation was that it is totally transparent in matlab. With the use of the open read write files commands, you can actually use the serial port to stream data to a peripheral. Our data rate was less that the first implementation at around 150KByte. There was room for improvement with this implementation as the microcontroller we were using had only 760Byte of data ram. But it made our life simpler with the testing. This is more or less the approach that we used to test a video processing system in HW. I wanted to say also that you should first try to simulate your solution as it will save you a lot of time. We used the read and write command as available in VHDL to initially generate intermediate results that we would eventually compare to our "golden" values, values obtained from matlab and known to be good. Jacques On Mar 9, 3:50=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Pritha Ghoshal <ghoshal.pri...@gmail.com> wrote: > > The algorithm will be simple - edge detection and colour > > conversion or something similar. > > And I need to mainly do the HDL code. Is some extra hardware crucial, > > or is it possible to work only with the computer and FPGA kit? > > For the problems I am used to, speed is very important. > If you just need to demonstrate a working algorithm, a parallel > port might be fine. =A0 > > The systolic array architecture (see Systolic_array in wikipedia) > is very different from the usual software implementation. =A0 > > To demonstrate that you understand the algorithm, speed isn't > important, though it is usually the reason behind hardware > implementations. > > -- glen
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