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
Peter Alfke wrote: > On Nov 29, 3:46 am, "heinerl...@googlemail.com" >> The problem we found is that the almost empty flag is only asserted if >> the FIFO is beeing emptied and not if it is beeing filled. So if the >> FIFO was empty and we get a shift in the almost empty is not asserted >> although we set the treshold to one. Is this a bug? You could use the fifo read count and compare it to 1? The latency may be higher, but it's guarantied there'll be a point there when it asserts. HTH, -P@Article: 126801
u_stadler@yahoo.de wrote: > when i was working with only one clock (the 100MHz one) my design > synthesized at about 450 MHz. > now when i connect the parts of my design that work with the different > clock rates it suddenly drops to 80 MHz. The design is not that big > (about 90 slices) so routing and placing should not be a problem. I > assume this has something to do with the two clock domains. > I wonder if ther is a state of the art way how to design with two > clock domains. (right now i'm using registers. is there anything > better or smarter? perhaps some examples ?) You should need to make sure that all paths that cross clock domains are protected against metastability, ie. adding pipelining of 2 or more clocks, depending on speed difference between clocks. Then you'd create a TimingIGnore (TIG) constraint on those paths, grouped with the FROM-TO grouping constraint. See the constraint guide for info. HTH, -P@Article: 126802
On Dec 2, 8:53 pm, PatC <p...@patocarr.com> wrote: > Peter Alfke wrote: > > On Nov 29, 3:46 am, "heinerl...@googlemail.com" > >> The problem we found is that the almost empty flag is only asserted if > >> the FIFO is beeing emptied and not if it is beeing filled. So if the > >> FIFO was empty and we get a shift in the almost empty is not asserted > >> although we set the treshold to one. Is this a bug? > > You could use the fifo read count and compare it to 1? The latency may > be higher, but it's guarantied there'll be a point there when it asserts. > > HTH, > -P@ In an asynchronous FIFO, the flags must be synchronized to the appropriate clock. The leading edge of Almost Empty is normally generated by the read clock, and it is the read side that usually worries about (Almost) Empty. The trailing edge, however, is generated by the write clock, and (for most purposes) needs re-synchronization to the read clock. That re-synchronization needs an extra clock edge (or two) to avoid metastable confusion. The basic problem is the unknown phase relationship between the two clocks. The edges can be far apart, but also very close to each other, down to fractional picoseconds. But the controller has to provide correct flag outputs. The actual reading and writing is trivial, as long as the RAM is dual-ported. Peter AlfkeArticle: 126803
Mark McDougall wrote: > Thanks for the tip Brian! This is certainly a possibility, as I'm a big > fan of aliases... I'll look into it with this in mind! > > How you found that, I have no idea, but thanks again! Hmmm, no dice. I removed std_logic_unsigned altogether, and there's no aliases in there that should affect it... :( Frustrating, because the design differs only from the Altera project in the memory block instantiations, and the DCM replacing the PLL. And a similar project, ported to Xilinx from Altera with much the same architecture, runs fine. :( Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 126804
psihodelia@googlemail.com wrote: > What I don't fully understand is why so many people use ModelSim ? I > did try it but it is slow and it has many bugs. On the other side, I Maybe because it is one of three big simulators that are known to support reliably the language standards and are fast. Also one critical thing in current world is support for mixed language designs. I have not seen pure vhdl for a while, usually there are some verilog blocks embedded to the designs. And in the future designs with systemc, systemverilog, vhdl and verilog are going to be normal. Also I have found that modelsim is very fast simulator. But you can't compare something like Modelsim XE and SE, they are different tools in terms of optimization capabilities. Also I have not seen more bugs in Modelsim than in other tools, and I have used it since 5.5 version, there have been few bad versions (for example 6.0 series). And many times the original source code has the bug, not the tool. Especially verilog based behavioral models many times seem to rely on how VerilogXL executed code, not on the language standard. And it might be that the tool did correct optimization, but the code was relying on execution order of the processes etc. > middle school. Today's complexity of the software is so huge that > almost all Closed Source Solutions are predefined to be buggy, And also open source software is buggy. The big problem with open source is support, for commercial EDA tools you actually get good support. Even if you have the code, you need people who really understand it, "here is the code, fix the problem yourself" does not usually work with complex codebases. > unproductive, short-living. The same arguments are applicable to the > current situation about synthesis tools. I wonder if current situation > will start slowly change. Commercial interests depend on the > technological progress. Progress will be faster if Open Source will be > more important. For example, many Universities could provide more Synthesis tools are even more complicated than simulators, and today there are even no good simulators at opensource side (multilanguage support, integrated gui, coverage support, assertions etc.) I'm fan of opensource, but it is not always the best way to develop tools. At synthesis side one problem for example is that the tool support for upcoming fpga-famimilies need to be started early on, and at that phase all information is under very strict NDAs. --KimArticle: 126805
HI as stated we are using the FIFO in an Asynchronous way. The read and write clock are both 200 MHz but are provided through 2 different oscillators. We are using the almost empty signal onlyin the read clock domain. We are currently implementing a single FF stage located at the output side of the FIFO. If then the FIFO goes empty (and the empty signal behaves correctly) we can be sure to have another datum in the FF stage, equaling almost empty. hope this helps.. regs, HeinerArticle: 126806
Op Thu, 29 Nov 2007 15:42:45 +0100 schreef Denkedran Joe <denkedranjoe@googlemail.com>: > I'm working on a hardware implementation (FPGA) of a lossless compression > algorithm for a real-time application. The data will be fed in to the > system, will then be compressed on-the-fly and then transmitted further. > > The average compression ratio is 3:1, so I'm gonna use some FIFOs of a > certain size and start reading data out of the FIFO after a fixed > startup-time. The readout rate will be 1/3 of the input data rate The > size > of the FIFOs is determined by the experimental variance of the mean > compression ratio. Nonetheless there are possible circumstances in which > no compression can be achieved. Given that uncompressible data often resembles noise, you have to ask yourself: what would be lost? > Since the overall system does not support > variable bitrates a faster transmission is no solution here. > > So my idea was to put the question to all of you what to do in case of > uncompressibility? Any ideas? If you can identify the estimated compression beforehand and then split the stream into a 'hard' part and an 'easy' part, then you have a way to retain the average. -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/Article: 126807
"KJ" <kkjennings@sbcglobal.net> writes: > Bottom line right now for the code I right, I'm finding Altera way > ahead of Xilinx and Synplify so I'm working with X and S to get > their tools improved so that they too can have less stuff that some > would consider to be 'not synthesizable'. Could you give us an example of something Altera can do that Synplify can't? (I've always "felt" Synplify to be ahead of the vendor-specific tools, but it sounds like that may have changed :-) Thanks! Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 126808
liqiyue@gmail.com wrote: > How can i interface the cyclone III with 2.5v LVDS to 3.3v LVDS adc & > dac ? > > Thanks If you set 3.3v to a i/o block and Quartus does not allow you to assign LVDS on a pin of that block (w/ an error message when fitting) tell quartus you have 2.5v (despite you will use 3.3v in your board) It will pass compilation and will work great. I had that issue on CycloneII driving clocks to ADCs from Analog devices, I'll bet will be the same on CyIII. lc.Article: 126809
"Boudewijn Dijkstra" <boudewijn@indes.com> writes: > Op Thu, 29 Nov 2007 15:42:45 +0100 schreef Denkedran Joe > <denkedranjoe@googlemail.com>: > > I'm working on a hardware implementation (FPGA) of a lossless compression > > algorithm for a real-time application. The data will be fed in to the > > system, will then be compressed on-the-fly and then transmitted further. > > > > The average compression ratio is 3:1, so I'm gonna use some FIFOs of a > > certain size and start reading data out of the FIFO after a fixed > > startup-time. The readout rate will be 1/3 of the input data rate > > The size > > of the FIFOs is determined by the experimental variance of the mean > > compression ratio. Nonetheless there are possible circumstances in > > which no compression can be achieved. > > Given that uncompressible data often resembles noise, you have to ask > yourself: what would be lost? *Much* more information than if the signal was highly redundant. > > Since the overall system does not support > > variable bitrates a faster transmission is no solution here. > > > > So my idea was to put the question to all of you what to do in case of > > uncompressibility? Any ideas? > > If you can identify the estimated compression beforehand and then > split the stream into a 'hard' part and an 'easy' part, then you have > a way to retain the average. Yeah, right. And if you juggle the bowling balls when crossing the rope-bridge, you'll not break the bridge. Phil -- Dear aunt, let's set so double the killer delete select all. -- Microsoft voice recognition live demonstrationArticle: 126810
Hi all I have read here that quite some people are encoutering problems with the Xilinx ISE tools. So for example the XST like to remove signals from the datapath although they are required. I recall that I used XST 6.2 two years ago and I successfully synthesised a design which was then working on the FPGA. I upgraded then to 7.1 and then exactly the same design wasnt working anymore?? In addition, I also think its quite difficult to trace this kind of errors at such a level. When the RTL simulation works fine, one would expect that after a successful synthese to have a working design, no? So I wonder if sythese tools from Cadence or Synopsis are better the Xilinx XST? I havent decided yet what tools to use in my design flow so any feedback is appreciated! Cheers!Article: 126811
On 3 Dez., 12:50, Mike <M...@yahoo.co.uk> wrote: > When the RTL simulation works fine, one would > expect that after a successful synthese to have a working design, no? No. You can only expect that if you are very careful with your simulation. Google for "HDL simulation mismatch". The simulator will execute your model. It does not check whether the model can be implemented in your target technology. For example there are many standard cell libraries that do not have flip-flops with power on reset. Still, the synthesis tool will create a netlist without error even if your code contains initial value assignments. Then of course your model of the stimulus of the design must be accurate. And you need 100% coverage for your testbench. Even with formal verification you can not guarantee that a correctly synthesized design will work as your simulation without putting in additional assumptions and knowledge. Kolja SulimmaArticle: 126812
>> How can i interface the cyclone III with 2.5v LVDS to 3.3v LVDS adc &
>> dac ?
>
>If you set 3.3v to a i/o block and Quartus does not allow you to
>assign LVDS on a pin of that block (w/ an error message when fitting)
>tell quartus you have 2.5v (despite you will use 3.3v in your board)
>It will pass compilation and will work great.
>I had that issue on CycloneII driving clocks to ADCs from Analog
>devices, I'll bet will be the same on CyIII.
For LVDS transmission from 3.3V I/O, if all three matching resistors
(at the transmitting end) are 150 ohm then this gives output levels to
the LVDS specification and presents 100 ohm to the line. The only
disadvantage (compared to 2.5V operation) is an increase in power
dissipation.
From removethisthenleavejea@replacewithcompanyname.co.uk Mon Dec 03 06:35:34 2007
Path: newssvr27.news.prodigy.net!newsdbm04.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!goblin2!goblin.stu.neva.ru!feeder.erje.net!feeder.news.heanet.ie!newsfeed.esat.net!news.clara.net!mephistopheles.news.clara.net!proxy02.news.clara.net
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Newsgroups: comp.arch.fpga
References: <48da85be-c67e-479c-8b6c-3824f5e98ee9@d61g2000hsa.googlegroups.com> <684b478a-032e-4c40-998e-6e55dad8ea6c@i12g2000prf.googlegroups.com> <9aa0272a-6372-4cf9-a429-cf85a9b584bb@b15g2000hsa.googlegroups.com>
Subject: Re: Traffic Light with counter
Date: Mon, 3 Dec 2007 14:35:34 -0000
Lines: 256
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-Complaints-To: abuse@clara.net (please include full headers)
X-Trace: 64e5e108c4b60584a594e000570080e1a0a244c2647c6277f66a4ae04754143d
NNTP-Posting-Date: Mon, 03 Dec 2007 14:35:41 +0000
Message-Id: <1196692541.26181.0@proxy02.news.clara.net>
Xref: prodigy.net comp.arch.fpga:138897
Start by defining a state machine that has all the states you need and
outline the transitions you need qualified with counter. An example (NOT
SYNTAX CHECKED) of 4 states below.
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
ENTITY TRAFFIC IS
PORT( CLOCK : IN STD_LOGIC;
RESET : IN STD_LOGIC;
OP1 : OUT STD_LOGIC;
OP2 : OUT STD_LOGIC);
END TRAFFIC;
ARCHITECTURE A0 OF TRAFFIC IS
SIGNAL COUNTER : INTEGER RANGE 0 TO 10000000;
TYPE SM_TRAFFIC_TYPE IS( SM_TRAFFIC_IDLE ,
SM_TRAFFIC_OP1_ON ,
SM_TRAFFIC_OP2_ON ,
SM_TRAFFIC_OP1_OP2_ON );
SIGNAL SM_TRAFFIC : SM_TRAFFIC_TYPE;
BEGIN
TR1 : PROCESS(RESET,CLOCK)
BEGIN
IF (RESET = '1') THEN
SM_TRAFFIC <= SM_TRAFFIC_IDLE;
COUNTER <= 1000;
OP1 <= '0';
OP2 <= '0';
ELSIF (CLOCK'EVENT AND CLOCK='1') THEN
CASE SM_TRAFFIC IS
WHEN SM_TRAFFIC_IDLE =>
SM_TRAFFIC <= SM_TRAFFIC_OP1_ON;
COUNTER <= 1000;
OP1 <= '1';
OP2 <= '0';
--STAY GERE 1000 CLOCKS
WHEN SM_TRAFFIC_OP1_ON =>
IF (COUNTER = 0) THEN
SM_TRAFFIC <= SM_TRAFFIC_OP2_ON;
COUNTER <= 5000000;
OP1 <= '0';
OP2 <= '1';
ELSE
SM_TRAFFIC <= SM_TRAFFIC_OP1_ON;
COUNTER <= COUNTER - 1;
OP1 <= '1';
OP2 <= '0';
END IF;
--STAY HERE 5000000 CLOCKS
WHEN SM_TRAFFIC_OP2_ON =>
IF (COUNTER = 0) THEN
SM_TRAFFIC <= SM_TRAFFIC_OP1_OP2_ON;
COUNTER <= 4000000;
OP1 <= '1';
OP2 <= '1';
ELSE
SM_TRAFFIC <= SM_TRAFFIC_OP2_ON;
COUNTER <= COUNTER - 1;
OP1 <= '0';
OP2 <= '1';
END IF;
--SM_TRAFFIC_OP1_OP2_ON
--STAY HERE 4000000 CLOCKS
WHEN OTHERS =>
IF (COUNTER = 0) THEN
SM_TRAFFIC <= SM_TRAFFIC_OP1_ON;
COUNTER <= 1000;
OP1 <= '1';
OP2 <= '0';
ELSE
SM_TRAFFIC <= SM_TRAFFIC_OP2_ON;
COUNTER <= COUNTER - 1;
OP1 <= '0';
OP2 <= '0';
END IF;
END CASE;
END IF;
END PROCESS TR1;
END A0 ;
John Adair
Enterpoint Ltd.
Home of Drigmorn1. The hobby FPGA Development Board.
"tang" <tarangpatel2electric@gmail.com> wrote in message
news:9aa0272a-6372-4cf9-a429-cf85a9b584bb@b15g2000hsa.googlegroups.com...
> On Dec 1, 1:59 am, John Adair <g...@enterpoint.co.uk> wrote:
>> There are a large number of ways you could do this. Personally I'm not
>> a get fan of next state, current state, style you use but it does have
>> it's followers.
>>
>> Staying with what you have I would check the asychronous
>> (combinatorial) processes have complete sensativity lists. Your
>> clocked processes I would make sure all statements lie with the clock
>> and reset statements.
>>
>> Personally I would have a counter that reloaded with values linked to
>> the transitions of the state machine and taking a count value relevant
>> to the state being entered. The counter then counts down to zero and
>> then the next state transition. If you make your counter integer type
>> you don't need extra numerical type libraries.
>>
>> John Adair
>> Enterpoint Ltd. - Home of Craignells The obsolete DIL solution.
>>
>> On 30 Nov, 22:12, tang <tarangpatel2elect...@gmail.com> wrote:
>>
>>
>>
>>
>>
>> > hey guys i hope u can help me out... i want to design a simple traffic
>> > light controller according to the 4 states shown in the code below. my
>> > only problem is that my signal state_reg is not changing form one
>> > state to another. this is because the counter i included in the the
>> > code as a process is not working. green to yellow time wait is 30 sec
>> > and yellow to red is 5 sec. my clock period will be 5 sec. so can
>> > anyone help me out
>>
>> > ------------------------------------------------------------------------------------------------------------------------------------------------------------
>> > library ieee;
>> > use ieee.std_logic_1164.all;
>> > use ieee.std_logic_arith.all;
>> > use IEEE.std_logic_unsigned.all;
>>
>> > entity TLC is
>> > port(
>> > clk,reset, sa, sb:in std_logic;
>> > Ga, Ya, Ra, Gb, Yb, Rb:out std_logic
>> > );
>> > end TLC;
>>
>> > architecture Behavioral of TLC is
>>
>> > type state_type is (a, b, c, d);
>> > signal state_reg, state_next: state_type;
>> > signal Pre_Q, Q: std_logic_vector(3 downto 0);
>> > signal count, clear: std_logic;
>>
>> > begin
>>
>> > -- behavior describe the counter
>> > process(clk, count, clear)
>> > begin
>> > if (clear = '0') then
>> > Pre_Q <= Pre_Q - Pre_Q;
>> > elsif (clk='1' and clk'event) then
>> > if (count = '1') then
>> > Pre_Q <= Pre_Q + 1;
>> > end if;
>> > end if;
>> > Q <= Pre_Q;
>> > end process;
>>
>> > -- state register
>>
>> > process(clk,reset)
>> > begin
>> > if(reset='0') then
>> > state_reg <= a;
>> > elsif (clk'event and clk='1') then
>> > state_reg <= state_next;
>> > end if;
>> > end process;
>>
>> > -- next state logic
>>
>> > process(state_reg,Q,sa,sb)
>> > begin
>>
>> > case state_reg is
>> > when a =>
>> > if(sa = '1' and sb = '0')then
>> > state_next <= a;
>> > elsif (sa = '0' and sb = '1') then
>> > count <= '1';
>> > if(Q = "0110") then
>> > state_next <= b;
>> > end if;
>> > end if;
>>
>> > when b =>
>>
>> > if(Q = "0111") then
>> > state_next <= c;
>> > count <= '0';
>> > elsif(sa = '1') then
>> > state_next <= b;
>> > end if;
>>
>> > when c =>
>> > if(sa = '0' and sb = '1') then
>> > state_next <= c;
>> > elsif (sa = '1' and sb ='0') then
>> > clear <= '0';
>> > count <= '1';
>> > if(Q = "0110") then
>> > state_next <= d;
>>
>> > end if;
>> > end if;
>>
>> > when d =>
>>
>> > if(Q = "0111") then
>> > state_next <= a;
>> > count <= '0';
>> > elsif(sb = '1') then
>> > state_next <= d;
>> > end if;
>> > end case;
>> > end process;
>>
>> > process (state_reg)
>> > begin
>> > Ga <= '1'; Ya <= '0'; Ra <= '0';
>> > Gb <= '0'; Yb <= '0'; Rb <= '1';
>>
>> > case state_reg is
>> > when a =>
>> > when b =>
>> > Ga <= '0';
>> > Ya <= '1';
>>
>> > when c =>
>> > Ya <= '0';
>> > Ra <= '1';
>> > Gb <= '1';
>>
>> > when d =>
>> > Gb <= '0';
>> > Yb <= '1';
>>
>> > end case;
>>
>> > end process;
>>
>> > end Behavioral;
>> > ----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Thanx for the solution. I was also thinking about making counter
> integer. Can you please elaborate on that? will it be like adding for
> loop till count reach to desired value and then perform the
> transition?
> thanx again
Article: 126813Mike wrote: > Hi all > > I have read here that quite some people are encoutering problems with > the Xilinx ISE tools. So for example the XST like to remove signals from > the datapath although they are required. I'd be really careful about making blanket statements about ISE problems based on postings to this forum because the original posters rarely update the thread when their problem is solved. In particular, unexpected logic optimization is a difficult problem to track down, so it's not uncommon for a new poster to ask for help, find their error and move on. If anything, that tells me we need better messages in the map report. --- Joe Samson Pixel VelocityArticle: 126814
Problems of this type are generally known by the technical term "insoluble". There must be an easing of one or more of the constraints. At least the OP has thought of one of the corner cases... BTW, doing this "in software" won't work either, as that still would require an unconstrained amount of memory to *never* fail.Article: 126815
To avoid going to a larger package, I want to mix LVDS_25 inputs with LVCMOS33 in the same I/O bank, with VCCO = 3.3V. I would also like to use the DIFF_TERM attribute on the LVDS inputs, to avoid external resistors, for better signal integrity and PCB routing. But apparently the LVDS differential termination uses VCCO, so it is required to be 2.5V with this attribute. Do I have any options to achieve what I want, or is there just no way. TIA, Barry BrownArticle: 126816
Hi Mike - You allusions to the ISE being a marginal product are incorrect. IMHO it is pretty good. In past, I ran into a problem on a successive release where previous instantiation of differential driver/receivers required a change in syntax ... Found the example in docs, modified code, and off and running in 15 minutes. I have 20+ designs in last 3 years I can speak to using XST flow. Comparing tools is a pretty personal task, and the comparison will vary depending on target design. I am a consultant, and tool expenses come out of pocket, so 20% improvement in synthesis time on a 5 minute synthesis are tough to justify. That might be different if I were designing in some of the bigger Virtex parts. Synplicity's features for incremental design, and floorplanning would be pretty attractive. I have not used the cadence tool. Be careful with terms like "ISE bugs" though. Sometimes I find the least experienced users discover the most tool bugs. -- Regards, John Retta Owner and Designer Retta Technical Consulting Inc. Colorado Based Xilinx Consultant phone : 303.926.0068 email : jretta@rtc-inc.com web : www.rtc-inc.comArticle: 126817
On Dec 3, 8:16 am, Barry <barry...@gmail.com> wrote: > To avoid going to a larger package, I want to mix LVDS_25 inputs with > LVCMOS33 in the same I/O bank, with VCCO = 3.3V. I would also like to > use the DIFF_TERM attribute on the LVDS inputs, to avoid external > resistors, for better signal integrity and PCB routing. But > apparently the LVDS differential termination uses VCCO, so it is > required to be 2.5V with this attribute. Do I have any options to > achieve what I want, or is there just no way. > > TIA, > Barry Brown The DIFF_TERM functionality is powered by 2.5V. Just add the external resistors and you can mix input I/Os to your heart's content.Article: 126818
Barry wrote: > To avoid going to a larger package, I want to mix LVDS_25 inputs with > LVCMOS33 in the same I/O bank, with VCCO = 3.3V. I would also like to > use the DIFF_TERM attribute on the LVDS inputs, to avoid external > resistors, for better signal integrity and PCB routing. But > apparently the LVDS differential termination uses VCCO, so it is > required to be 2.5V with this attribute. Do I have any options to > achieve what I want, or is there just no way. You can use the internal termination even if VCCO=3.3V, but then the termination value is not 100 Ohms. What the value really is is not specified, since it's not recommended to be used this way, but you can do it without "hurting" the FPGA or anything. I have used this configuration on a Virtex4-device, worked without any problems (but the LVDS signal wasn't very fast and the connections short). Another problem is that since ISE9.1 the tools won't allow you to put LVDS-Inputs in the same bank as LVTTL-outputs; par then just quits with a fatal error message (tool versions before that didn't even issue a warning). If you want to override that you have to set the environment variable "PL_NO_SIO_DRC" to 1. The best solution is probably to provide external termination resistors, like John said. If you use 0402 resistors you can usually put them on the opposite side of the PCB right between or even on top of the vias that come down from the FPGA balls. HTH, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 126819
On Dec 3, 4:14 am, "Boudewijn Dijkstra" <boudew...@indes.com> wrote: > Op Thu, 29 Nov 2007 15:42:45 +0100 schreef Denkedran Joe > <denkedran...@googlemail.com>: > > > I'm working on a hardware implementation (FPGA) of a lossless compression > > algorithm for a real-time application. The data will be fed in to the > > system, will then be compressed on-the-fly and then transmitted further. > > > The average compression ratio is 3:1, so I'm gonna use some FIFOs of a > > certain size and start reading data out of the FIFO after a fixed > > startup-time. The readout rate will be 1/3 of the input data rate The > > size > > of the FIFOs is determined by the experimental variance of the mean > > compression ratio. Nonetheless there are possible circumstances in which > > no compression can be achieved. > > Given that uncompressible data often resembles noise, you have to ask > yourself: what would be lost? The message! Just because the message "resembles" noise does not mean it has no information. In fact, just the opposite. Once you have a message with no redundancy, you have a message with optimum information content and it will appear exactly like noise. Compression takes advantage of the portion of a message that is predictable based on what you have seen previously in the message. This is the content that does not look like noise. Once you take advantage of this and recode to eliminate it, the message looks like pure noise and is no longer compressible. But it is still a unique message with information content that you need to convey. > > Since the overall system does not support > > variable bitrates a faster transmission is no solution here. > > > So my idea was to put the question to all of you what to do in case of > > uncompressibility? Any ideas? > > If you can identify the estimated compression beforehand and then split > the stream into a 'hard' part and an 'easy' part, then you have a way to > retain the average. Doesn't that require sending additional information that is part of the message? On the average, this will add as much, if not more to the message than you are removing... If you are trying to compress data without loss, you can only compress the redundant information. If the message has no redundancy, then it is not compressible and, with *any* coding scheme, will require some additional bandwidth than if it were not coded at all. Think of your message as a binary number of n bits. If you want to compress it to m bits, you can identify the 2**m most often transmitted numbers and represent them with m bits. But the remaining numbers can not be transmitted in m bits at all. If you want to send those you have to have a flag that says, "do not decode this number". Now you have to transmit all n or m bits, plus the flag bit. Since there are 2**n-2**m messages with n+1 bits and 2**m messages with m+1 bits, I think you will find the total number of bits is not less then just sending all messages with n bits. But if the messages in the m bit group are much more frequent, then you can reduce your *average* number of bits sent. If you can say you will *never* send the numbers that aren't in the m bit group, then you can compress the message losslessly in m bits.Article: 126820
"Barry" <barry374@gmail.com> wrote in message news:7a60bfbf-0bfc-4599-9f57-99b892c23a03@n20g2000hsh.googlegroups.com... > To avoid going to a larger package, I want to mix LVDS_25 inputs with > LVCMOS33 in the same I/O bank, with VCCO = 3.3V. I would also like to > use the DIFF_TERM attribute on the LVDS inputs, to avoid external > resistors, for better signal integrity and PCB routing. But > apparently the LVDS differential termination uses VCCO, so it is > required to be 2.5V with this attribute. Do I have any options to > achieve what I want, or is there just no way. > Hi Barry, What's the rise time of the LVDS signals you want to terminate? Are they driven from a source that has 'proper' LVDS source termination? http://pdfserv.maxim-ic.com/en/an/hfan10v2.pdf fig.6 shows source termination. Syms.Article: 126821
On Nov 30, 5:15 pm, "KJ" <kkjenni...@sbcglobal.net> wrote: > "rickman" <gnu...@gmail.com> wrote in message > > > The examples are far too numerous to list, but here is one. > <snip> > > To make this unsynthesizable in a way that is sometimes attempted by > > newbies... > > > Example2: process (SysClk, Reset) begin > > if (Reset = '1') then > > DataOutReg <= (others => '0'); > > elsif (rising_edge(SysClk) or falling_edge(SysClk)) then > > if (SCFG_CMD = '1') THEN > > DataOutReg <= TT & SD & PCMT0 & PCMT1 & WP_SDO0 & WP_SDO1 & DTR & > > RTS; > > end if; > > end if; > > end process Example2; > > > You can imagine a register that clocks on both the rising and falling > > edge, but you can't build it in an FPGA. > > But that does not imply that it couldn't be synthesized using two sets of > flip flops whose results get combined. You might not find a synthesis tool > in 2007 that accepts the above code, but that doesn't mean that there won't > be one in 2008 that will. Whether there is such a tool or not depends on > how many users scream to brand A and X that they really need this. It can > be synthesized, just not how you are focusing on how you think it must be > synthesized. If you can build the second description, I would like to see that. Do you know this is possible or are you just speculating? I have never seen a good example of a register clocked on both edges done in an FPGA.Article: 126822
KJ wrote:
> Bottom line right now for the code I right, I'm
> finding Altera way ahead of Xilinx and Synplify so I'm working with X and S
> to get their tools improved so that they too can have less stuff that some
> would consider to be 'not synthesizable'.
Synplify used to have it over quartus on viewers,
but quartus has caught up. As far as synthesis,
it varies with the design, but I would call
A and S comparable for an altera target.
X needs some focus on advanced synthesis.
For example, I wish they would take this one seriously:
http://home.comcast.net/~mike_treseler/proc_demo.vhd
http://home.comcast.net/~mike_treseler/proc_demo_ise_bug.pdf
http://home.comcast.net/~mike_treseler/proc_demo_ise_fix.pdf
It has been hanging fire since ISE 6.1i,
It wouldn't be so bad if I got an error message.
I get synthesis that does not match simulation.
The suggested "solution"
http://www.xilinx.com/support/answers/18452.htm
is to avoid the legal code that causes the problem.
Note that brand A and S and Modelsim get it right.
-- Mike Treseler
Article: 126823On Dec 3, 9:35 am, "Symon" <symon_bre...@hotmail.com> wrote: > "Barry" <barry...@gmail.com> wrote in message > > news:7a60bfbf-0bfc-4599-9f57-99b892c23a03@n20g2000hsh.googlegroups.com... > > > To avoid going to a larger package, I want to mix LVDS_25 inputs with > > LVCMOS33 in the same I/O bank, with VCCO = 3.3V. I would also like to > > use the DIFF_TERM attribute on the LVDS inputs, to avoid external > > resistors, for better signal integrity and PCB routing. But > > apparently the LVDS differential termination uses VCCO, so it is > > required to be 2.5V with this attribute. Do I have any options to > > achieve what I want, or is there just no way. > > Hi Barry, > What's the rise time of the LVDS signals you want to terminate? Are they > driven from a source that has 'proper' LVDS source termination?http://pdfserv.maxim-ic.com/en/an/hfan10v2.pdffig.6 shows source > termination. > Syms. The driver is a Texas Instruments ADS6244 ADC. Rise time is spec'd between 50 and 200 psec (from -100mV to +100mV), and my data rate will be 800Mbps. The device's LVDS drivers have a configurable internal termination, which I can set to 100 ohm differential if I desire, at the expense of a little more power dissipation.Article: 126824
On Dec 3, 9:13 am, Sean Durkin <news_de...@durkin.de> wrote: > Barry wrote: > > To avoid going to a larger package, I want to mix LVDS_25 inputs with > > LVCMOS33 in the same I/O bank, with VCCO = 3.3V. I would also like to > > use the DIFF_TERM attribute on the LVDS inputs, to avoid external > > resistors, for better signal integrity and PCB routing. But > > apparently the LVDS differential termination uses VCCO, so it is > > required to be 2.5V with this attribute. Do I have any options to > > achieve what I want, or is there just no way. > > You can use the internal termination even if VCCO=3.3V, but then the > termination value is not 100 Ohms. What the value really is is not > specified, since it's not recommended to be used this way, but you can > do it without "hurting" the FPGA or anything. I have used this > configuration on a Virtex4-device, worked without any problems (but the > LVDS signal wasn't very fast and the connections short). > > Another problem is that since ISE9.1 the tools won't allow you to put > LVDS-Inputs in the same bank as LVTTL-outputs; par then just quits with > a fatal error message (tool versions before that didn't even issue a > warning). If you want to override that you have to set the environment > variable "PL_NO_SIO_DRC" to 1. > > The best solution is probably to provide external termination resistors, > like John said. If you use 0402 resistors you can usually put them on > the opposite side of the PCB right between or even on top of the vias > that come down from the FPGA balls. > > HTH, > Sean > > -- > My email address is only valid until the end of the month. > Try figuring out what the address is going to be after that... Thanks, Sean. I will probably have to use external resistors then. And thanks for the tip on the environment variable.
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