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 Fri, 26 Sep 2003 07:15:44 GMT, "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote: >"Bob Feng" wrote: >> Your comments after your question do not make sense to me. > >You are thinking computers. I'm thinking video. > >Here's one possible scenario. You are required to overlay graphics >(primitives: lines, circles, etc.) and text onto an incoming video feed, >which is then output in the same format. The allowable input to output >delay is in the order of just a few clocks --if that much at all-- not >frames, not lines, a few clocks at best. > >Frame buffers are out of the question, of course. I don't see how this follows from your constraints. You say that the input to output video delay is at most a few clocks, however you don't indicate that this constraint applies to the overlay, e.g. the overlay could come from a frame buffer and then be combined with the incoming video using some low latency method (either digital or analog, using e.g. the analog switch method you mentioned). You would need to genlock the FPGA generated video to the incoming video, but that's not too hard. >In addition to this, due >to cost constraints, you are not allowed to have rendering memory for the >graphics overlay. You, therefore, must render text and graphics on the fly, >in real time, as the signal flows through. I would expect that the cost of a cheap FPGA + cheap memory + simple design would be much less than the cost of a larger FPGA + complex design. (Actually, I think the cost of the ram will be less than the cost of fitting the heatsink you'll need if you don't have a ram. :) IOW, due to cost constraints, you should have rendering memory for the graphics overlay. Of course, you'll need to do a detailed costing to be sure, but I'd be surprised if the version with ram doesn't end up being cheaper and get to market sooner. Note that larger FPGAs may be able to hold the frame buffer in internal ram (but this depends on your resolution and pixel depth). Regards, Allan.Article: 61001
Get your own domain name (register privately with no info about you revealed) and email addresses in your private domain which you can easily control. I did it a couple of years ago now and got an address for me and one each for the family. Spam blocking software can be included, web mail access is available, and you can switch ISP's at any time and be independent of their spam-ridden email systems. Web hosting is also there if you need it. Got mine from www.mydoname.com and for about $20 per year, it's a steal. "jaideep" <jaideep@sasken.com> wrote in message news:c4312ee4.0309252242.2fa34638@posting.google.com... > Jan Panteltje <panteltjeNSOAPM@yahoo.com> wrote in message news:<1064411674.535376@evisp-news-01.ops.asmr-01.energis-idc.net>... > > What more can I say: I lost yahoo now. > > That virus searches Usenet for email addresses, and then sends > > thousands of times that microft fix with the worm. > > Hi, > > I am also facing the same problem.Is there a fix to avoid this? > > Regards, > > JaideepArticle: 61002
charles.elias@wpafb.af.mil (Charles M. Elias) wrote in message news:<35849667.0309250248.5c8b4ef3@posting.google.com>...
> fpga_uk@yahoo.co.uk (Isaac) wrote in message news:<889eb3fb.0309240705.2bb5e86c@posting.google.com>...
>
>
> Without seeing your code it is not possible to make an exact diagnosis
> (maybe I couldn't even if I did see it), but I do have suggestions.
> Any signal that is an input to the FPGA synchronous logic should be
> internally synchronized with the logic's clock using 2 d flip-flops.
> The bus data need not be synchronized in this manner if the transfer
> logic (handshake) is synchronized. The read operation should have
> some sort of handshake to ensure that the output data is stable before
> it is read and that the FPGA logic "knows" when new data is requested.
> Does PCI protocol involve a handshake? If so, have you implemented
> it on the FPGA side?
>
> A typical handshake would be: The reader asserts data_request; the
> FPGA logic puts the data on the bus and asserts data_ready. The
> reader sees data_ready, reads the data, and unasserts data_request
> (this lets the FPGA logic know that the data has been read and it
> unasserts data_ready and). There are a number of variations on this,
> but without some sort of handshake it is quite likely that there will
> be missed data, multiple reads of the same data, etc.
>
> Charles
--------------------
> Without seeing your code it is not possible to make an exact diagnosis
> (maybe I couldn't even if I did see it), but I do have suggestions.
> Any signal that is an input to the FPGA synchronous logic should be
> internally synchronized with the logic's clock using 2 d flip-flops.
> The bus data need not be synchronized in this manner if the transfer
> logic (handshake) is synchronized. The read operation should have
> some sort of handshake to ensure that the output data is stable before
> it is read and that the FPGA logic "knows" when new data is requested.
> Does PCI protocol involve a handshake? If so, have you implemented
> it on the FPGA side?
>
> A typical handshake would be: The reader asserts data_request; the
> FPGA logic puts the data on the bus and asserts data_ready. The
> reader sees data_ready, reads the data, and unasserts data_request
> (this lets the FPGA logic know that the data has been read and it
> unasserts data_ready and). There are a number of variations on this,
> but without some sort of handshake it is quite likely that there will
> be missed data, multiple reads of the same data, etc.
>
> Charles
-------------------------------------------------------------------
Here is the Case Statement which I am using, in this you will see
different signal which I am using in differnt process which I haven't
included .
process1: process (CLK_2X)
begin
if RISING_EDGE(CLK_2X) then
state <= next_state;
else
Null;
end if;
end process process1;
process2 : process
(state,LOCKED,CLK_2X,SR_ADDR_IO,SR_DATA_IO,SR_IRD,SR_IWR,SR_IVCS_V3)
begin
case state is
when s1 =>
paritycheck <= '0';
k <= 0;
next_state <= s2;
when s2 =>
if LOCKED = '1' then
-- LED_V3 <= LED_V3_int;
STAT_V3 <= STAT_V3_int;
-- Inputs
-- SR_ADDR_IO_int <= SR_ADDR_IO;
-- SR_DATA_IO_int <= SR_DATA_IO;
-- SR_IRD_int <= SR_IRD;
-- SR_IWR_int <= SR_IWR;
SR_IVCS_V3_int <= SR_IVCS_V3;
next_state <= s3; else
Null;
end if;
when s3 =>
if SR_IVCS_V3 = '0' then
SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
if SR_IWR = '0' then
if SR_ADDR_IO = "000000" then
channelbit1 <= SR_DATA_IO(2 downto 0) ;
next_state <= s32;
else
next_state <= s3;
end if ;
else
Null;
end if ;
else
Null;
end if;
when s32 =>
if SR_IVCS_V3 = '0' then
SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
if SR_IWR = '0' then
if SR_ADDR_IO = "000001" then
channelbit2 <= SR_DATA_IO(2 downto 0) ;
next_state <= s33;
else
next_state <= s32;
end if ;
else
Null;
end if ;
else
Null;
end if;
when s33 =>
if SR_IVCS_V3 = '0' then
SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
if SR_IWR = '0' then
if SR_ADDR_IO = "000010" then
channelbit3 <= SR_DATA_IO(2 downto 0) ;
next_state <= s34;
else
next_state <= s33;
end if ;
else
Null;
end if ;
else
Null;
end if;
when s34 =>
if SR_IVCS_V3 = '0' then
SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
if SR_IWR = '0' then
if SR_ADDR_IO = "000011" then
channelbit4 <= SR_DATA_IO(2 downto 0) ;
next_state <= s35;
else
next_state <= s34;
end if ;
else
Null;
end if ;
else
Null;
end if;
when s35 =>
if SR_IVCS_V3 = '0' then
SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
if SR_IWR = '0' then
if SR_ADDR_IO <= "000100" then
channelbit5 <= SR_DATA_IO(2 downto 0) ;
next_state <= s36;
else
next_state <= s35;
end if ;
else
Null;
end if ;
else
Null;
end if;
when s36 =>
if SR_IVCS_V3 = '0' then
SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
if SR_IWR = '0' then
if SR_ADDR_IO = "000101" then
channelbit6 <= SR_DATA_IO(2 downto 0) ;
next_state <= s37;
else
next_state <= s36;
end if ;
else
Null;
end if ;
else
Null;
end if;
when s37 =>
if SR_IVCS_V3 = '0' then
SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
if SR_IWR = '0' then
if SR_ADDR_IO = "000110" then
channelbit7 <= SR_DATA_IO(2 downto 0) ;
next_state <= s38;
else
next_state <= s37;
end if ;
else
Null;
end if ;
else
Null;
end if;
when s38 =>
if SR_IVCS_V3 = '0' then
SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
if SR_IWR = '0' then
if SR_ADDR_IO = "000111" then
channelbit8 <= SR_DATA_IO(2 downto 0) ;
next_state <= s39;
else
next_state <= s38;
end if ;
else
Null;
end if ;
else
Null;
end if;
when s39 =>
if SR_IVCS_V3 = '0' then
SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
if SR_IWR = '0' then
if SR_ADDR_IO = "001000" then
channelbit9 <= SR_DATA_IO(2 downto 0) ;
next_state <= s310;
else
next_state <= s39;
end if ;
else
Null;
end if ;
else
Null;
end if;
when s310 =>
if SR_IVCS_V3 = '0' then
SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
if SR_IWR = '0' then
if SR_ADDR_IO = "001001" then
channelbit10 <= SR_DATA_IO(2 downto 0) ;
next_state <= s311;
else
next_state <= s310;
end if ;
else
Null;
end if ;
else
Null;
end if;
when s311 =>
if SR_IVCS_V3 = '0' then
SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
if SR_IWR = '0' then
if SR_ADDR_IO = "001010" then
channelbit11 <= SR_DATA_IO(2 downto 0) ;
next_state <= s312;
else
next_state <= s311;
end if ;
else
Null;
end if ;
else
Null;
end if ;
when s312 =>
if SR_IVCS_V3 = '0' then
SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
if SR_IWR = '0' then
if SR_ADDR_IO = "001011" then
channelbit12 <= SR_DATA_IO(2 downto 0) ;
LED_V3(2 downto 0) <= channelbit11;
next_state <= s4;
else
next_state <= s312;
end if ;
else
Null;
end if ;
else
Null;
end if;
when s4 =>
k <= k + 1;
next_state <= s5;
when s5 =>
if remainder = 0 then
k <= 0;
next_state <= s6 ;
paritycheck <= '1';
else
next_state <= s4 ;
k<= k+1;
end if ;
when s6 =>
if SR_IVCS_V3 = '0' then
if SR_IRD = '0' then
-- if remainder = 0 then
if SR_ADDR_IO = "001100" then
SR_DATA_IO (11 downto 0)<= eb_hat_bits (0 to 11);
SR_DATA_IO (31 downto 12) <= "00000000000000000000";
elsif SR_ADDR_IO = "001101" then
next_state <= s1;
end if;
-- end if;
else
Null;
end if;
else
Null;
end if ;
when others =>
Null;
end case;
end process process2;
Article: 61003Ok I was confused. I did implement a synchronous counter as everybody points out. The glitches are due to routing delays in the FPGA. Now Im not confused any more. All I need now is to find verilog for a 16 bit gray code counter. Many thanks Denis "Bob Feng" <yi.feng@sbcglobal.net> wrote in message news:<XLPcb.3437$6b6.3086@newssvr29.news.prodigy.com>... > I am confused by your terminology. > > Correct me if I am wrong. > 1. You are looking for a "synchrounous binary counter". Isn't it the one you > just wrote? > 2. What is the matter with ripple counter? And what is the difference from a > "synchrounous binary counter"? > 3. Gray code should be able to walk through all the addresses. > > ---Bob > "Denis Gleeson" <dgleeson-2@utvinternet.com> wrote in message > news:184c35f9.0309250354.763cf662@posting.google.com... > > Hello All > > > > OK Im a bit confused. > > > > the verilog code > > > > always @(posedge CLK or posedge CLR) > > begin > > if (CLR) > > Q <= 20'b0; > > else > > if (CE) // Is counter Enabled. > > begin > > Q<=Q+1; > > end > > end > > > > produces a ripple counter? Yes, No? > > > > When I look at my simulation results I see glitches in the count output > > leading me to assume that I have implemented a ripple counter. > > > > IS it possible to remove the glitches with a synchronous Binary counter? > > If yes what is the verilog code? > > > > Ive read about Gray counters but as Im using the counter to step through > > SRAM addresses I dont want to loose storage locations in my SRAM just > because > > my counter doesnt count through all possible binary counts. > > > > > > Thanks in advance for all suggestions. > > > > > > DenisArticle: 61004
The same with me. Luiz CarlosArticle: 61005
What parts are the plug and play? Why is there a separate IEEE1284_IN and out port? Couldn't that be the same 8bit bidirectional port? Also, I asked if I could get the EPP VHDL that you mentioned, but I had to change my email address because of the current virus going around was swamping my incoming messages. My new email is jlw@williams-eng.com Regards, James "Antti Lukats" <antti@case2000.com> wrote in message news:80a3aea5.0309252122.75ef10c2@posting.google.com... > "James Williams" <james@williams-eng.com> wrote in message news:<bkv30s$pp0$1@news3.infoave.net>... > > I found that it did synthesise into an XC95144, however is does not fit into > > the device use the fitter of the ISE. > > > > Regards, > > with plug and play and debug disabled it fits into XC9572 with ISE > > anttiArticle: 61006
Hi all,
I want the code below to synthesize as a FF with a sync reset and CE,
however XST does something quite different (target technology is Virtex II).
It routes my clk_ena signal to the REV pin and ties D and CE to VCC. The
sync_reset is recognized OK and gets routed correctly to the SR pin. I
realize that if I had a "regular" input signal instead of '1' under the
clock enable statement it would have worked fine, but what should I do if I
need to tie it to VCC?
process(clk)
begin
if rising_edge (clk) then
if sync_reset='1' then
outf <= '0';
elsif clk_ena='1' then
outf <= '1';
end if;
end if;
end process;
Thanks,
/Mikhail
Article: 61007Rick, Sorry to have offended, but you really are arguing a lost cause. Ignore SI? At your peril. And not (just) for relibility reasons, just plain work reasons. As for your example, of less than 12", and 3.300V, again, I ask you to go simulate the exact situation you are asking about. What impedance trace? What strength driver? What is(are) the load(s)? What is potentially coupling to the trace(s)? Too many variables to just say: "hey, no problem." By the way, I would never state "hey, no problem," as Murphy says, "whatever can go wrong, will go wrong...." that is why we simulate. Austin rickman wrote: > I find your tone offensive Austin. I am simply trying to understand the > issue being discussed by yourself as well as others. On my board there > will be no traces that are near 12" much less 24" and the power supply > will not be 3.6 volts. So what you are now talking about is not a > typical board design, but rather a *bad* board design. That is not what > you said. Your statements, as well as others, was that *every* board > needs to be simulated. I agree that clock signals are very sensitive to > signal integrity, but most data lines, that are not excessively long, > will do no hard to most chips and SI issues will only add to the setup > time. > > So if my traces are 6" and under and my Vccio is 3.3 volts or less, is > it likely that a data trace will be at issue if it is not simulated? As > I said, this is the first time I have heard anyone say that it can be an > issue, *especially* an issue of doing damage to a chip. > > Ringing has been an accepted part of digital logic design since logic > was invented. It is a problem, not because it exists, but only if it > creats a malfunction. It can ring for an hour and I won't care if I > have two hours of settling time on my bus. > > If you don't wish to discuss this politely, then please feel free to > ignore my post. > > Austin Lesea wrote: > > > > Rick, > > > > Get off that horse: 'typical' ringing is not the issue here. > > > > Have said it a number of times: overshoot and undershoot is bad (period), and is > > a sign of a bad board design. The fact that if you have > > > > 1) 85C Tj AND > > 2) you have a power supply at 3.6 volts AND > > 3) you have crappy SI over long t-lines (which store more energy -- like 12 - 24") > > > > MAY lead to exceeding the Abs Max spec. > > > > The point is that you have to simulate to get good SI, so do so. While you are at > > it, if the SI is terrible, fix it. If you can't fix it, then make sure you are > > within the Abs Max specs. > > > > Austin > > > > rickman wrote: > > > > > Austin Lesea wrote: > > > > > > > > Rick, > > > > > > > > Fight it as long as you can, but everyone else is using the more advanced > > > > tools, and simulating everything (at the companies where they want to be > > > > successful on the first pcb turn -- as for the others, I don't hear from > > > > them often anymore....). > > > > > > Funny. But I doubt it is very accurate. I have worked at some of the > > > larger companies making telecom test equipment and I have yet to meet a > > > board designer who simulates all of the traces. The ones I spoke with > > > only simulate the clock lines or other signal lines when the timing is > > > tight with no time for settling. > > > > > > Like I said, this is the first time I have heard a chip maker claim that > > > typical ringing and undershoot can cause chip damage. Of course an > > > absurdly designed trace and create excessive swings. But the typical > > > amount of ringing is normally listed in data sheets as being within spec > > > for chips. > > > > > > > And yes, if you do not pay attention now, you will cause ground bounce (50 - > > > > 60 mA of reflection current per IO is possible), > > > > > > Under what conditions is this "possible"? I would expect this to be an > > > extreme case. The analyis listed here indicated much lower currents > > > (~35 mA) and only for the brief time (< 1 ns) of the overshoot. If the > > > device can't handle these low currents without ground bounce, how can it > > > possibly provide the much larger currents (> 55 mA) for the initial > > > level change without ground bounce? > > > > > > > and with the Virtex II Pro, > > > > and Spartan 3 if the IOs are operated at 3.3V, you may exceed the Abs Max > > > > data sheet limits if you do not pay attention to what you are doing. And > > > > that will cause a reduction in the 20 year projected lifetime. Below 3.0V, > > > > there are no reliability issues to consider, as the clamp diodes are > > > > sufficient to protect the IOs. Smaller, faster, less expensive technology > > > > from the foundries has some drawbacks: leakage current, and IO robustness > > > > at voltages greater than 3.75 volts being two of them. > > > > > > > > The new tools allow for extraction of all pcb parameters, and easy > > > > simulation of all tracks/traces. You can also create a design that is > > > > correct by construction: use DCI or series or parallel termination, and > > > > make 50 ohm (or whatever) traces. Then you do not have to simulate > > > > everything. > > > > > > So the DCI in the S3 chips will allow matching of the chip IO impedance > > > to the trace, right? > > > > > > > Or use a standard: HSTL, SSTL, PCI. Then you also don't have to think. > > > > But I also simulate to make sure I haven't missed anything. > > > > > > I only wish standards really did preclude the "thinking". I have worked > > > with RS-232 and many others too long to beleive that. > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > Ignore the reply address. To email me use the above address with the XY > > > removed. > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > 4 King Ave 301-682-7772 Voice > > > Frederick, MD 21701-3110 301-682-7666 FAX > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 61008
MM wrote:
> Hi all,
>
> I want the code below to synthesize as a FF with a sync reset and CE,
> however XST does something quite different (target technology is Virtex II).
> It routes my clk_ena signal to the REV pin and ties D and CE to VCC.
XST is just doing its job, making a valid netlist per your description.
A synth will often do unexpected things, but it will work just fine.
> The
> sync_reset is recognized OK and gets routed correctly to the SR pin. I
> realize that if I had a "regular" input signal instead of '1' under the
> clock enable statement it would have worked fine,
Both are "fine".
You write the description, the synth makes the netlist.
-- Mike Treseler
-- makes an fdre module on Virtex:
library ieee;
use ieee.std_logic_1164.all;
entity sreset_ce is
port (
clk : in std_ulogic;
clk_ena : in std_ulogic;
sync_reset : in std_ulogic;
inf : in std_ulogic;
outf : out std_ulogic);
end entity sreset_ce;
architecture synth of sreset_ce is
begin
process(clk) is
begin
if rising_edge (clk) then
if sync_reset = '1' then
outf <= '0';
elsif clk_ena = '1' then
outf <= inf;
end if;
end if;
end process;
end architecture synth;
Article: 61009If your syntax does work, you can see the pullup in the FPGA Editor for your Placed & Routed design. Find one of the IOBs, double click on the IOB and you'll get a pop-up for just that cell. Included are checkboxes for some of the IOB options including logic standard, fast/slow, and pullup. If the pullup isn't indicated *there* it isn't in your finalized design. "Max" <cialdi@firenze.net> wrote in message news:8e077568.0309252330.21aae0c5@posting.google.com... > I use xilinx ise webpack 6.1 sp1. > In may project I tried to add contrains like: > > NET "probes<0><0>" LOC = "D11" | PULLUP ; > NET "probes<0><1>" LOC = "D12" | PULLUP ; > NET "probes<0><2>" LOC = "C12" | PULLUP ; > > This signals are all input. > > In translate report is reported: > > Attached a PULLUP primitive to pad net probes<0><2> > Attached a PULLUP primitive to pad net probes<0><1> > Attached a PULLUP primitive to pad net probes<0><0> > > > But in place&route report there is no reference to pullups: > Resolved that IOB <probes<0><0>> must be placed at site D11. > Resolved that IOB <probes<0><1>> must be placed at site D12. > Resolved that IOB <probes<0><2>> must be placed at site C12. > > Even in pad report is not mentioned pullup resistor for that signals. > > How can I be sure about the presence of pullup resistors on that ports? > > thanksArticle: 61010
My fix was to stop forwarding my mail to my Verizon.com isp and redirect it to my email-only account with nwlink.com. Verizon doesn't filter the junk. My forwarding service mail.com doesn't filter the junk. NWlink.com filters out the "microsoft patch" junk easily. Beautiful. Some ISPs are on the ball. "jaideep" <jaideep@sasken.com> wrote in message news:c4312ee4.0309252242.2fa34638@posting.google.com... > Jan Panteltje <panteltjeNSOAPM@yahoo.com> wrote in message news:<1064411674.535376@evisp-news-01.ops.asmr-01.energis-idc.net>... > > What more can I say: I lost yahoo now. > > That virus searches Usenet for email addresses, and then sends > > thousands of times that microft fix with the worm. > > Hi, > > I am also facing the same problem.Is there a fix to avoid this? > > Regards, > > JaideepArticle: 61011
Mikhail, Your last statement suggests a solution. Have you tried creating signal and assigning that to one outside of the process? I this may (or may not) work. If you absolutely want some particular interconnect configuration of a Xilinx Basic Element you can always instantiate any component in the the unisim library (unisim_VCOMP.vhd) FDRE in this case I'll also just mention XST implementation is logically correct even if it wasn't what you wanted. Chris MM wrote: > Hi all, > > I want the code below to synthesize as a FF with a sync reset and CE, > however XST does something quite different (target technology is Virtex II). > It routes my clk_ena signal to the REV pin and ties D and CE to VCC. The > sync_reset is recognized OK and gets routed correctly to the SR pin. I > realize that if I had a "regular" input signal instead of '1' under the > clock enable statement it would have worked fine, but what should I do if I > need to tie it to VCC? > > process(clk) > begin > if rising_edge (clk) then > if sync_reset='1' then > outf <= '0'; > elsif clk_ena='1' then > outf <= '1'; > end if; > end if; > end process; > > Thanks, > /MikhailArticle: 61012
"Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message news:3F745C28.4090401@flukenetworks.com... > MM wrote: > > Hi all, > > > > I want the code below to synthesize as a FF with a sync reset and CE, > > however XST does something quite different (target technology is Virtex II). > > It routes my clk_ena signal to the REV pin and ties D and CE to VCC. > > XST is just doing its job, making a valid netlist per your description. > A synth will often do unexpected things, but it will work just fine. I don't think the netlist is valid. With D and CE both tied to VCC the flop reverts to '1' on every clock regardless of my clk_ena signal. This is a part of a bigger design that used to work on Spartan II. I only found the problem when I moved it to Virtex II.... Any other ideas? Thanks, /MikhailArticle: 61013
On 26 Sep 2003 06:08:08 -0700, dgleeson-2@utvinternet.com (Denis
Gleeson) wrote:
>Ok I was confused.
>
>I did implement a synchronous counter as everybody points out.
>The glitches are due to routing delays in the FPGA.
>
>Now Im not confused any more.
>
>All I need now is to find verilog for a 16 bit gray code counter.
Try this. Credit where credit is due: as noted in the comments, the
gray code calculation comes from a paper by Cliff Cummings.
Bob Perlman
Cambrian Design Works
//===============================================================
// Module
//===============================================================
//
// Module: gray_ctr_module.v
//
// Author: Bob Perlman
//
// Description: The Verilog code for a gray-code counter
// incorporates a gray-to-binary converter, a binary-
// to-gray converter and increments the binary value
// between conversions.
//
// This code was based on Cliff Cummings' 2001 SNUG paper,
// "Synthesis and Scripting Techniques for Designing
// Multi-Asynchronous Clock Designs."
//
// Revision history:
// Rev. Date Modification
// ---- --------
----------------------------------------------
// - 12/29/01 Baseline version
`timescale 1 ns / 1 ps
module gray_ctr_module
(// Outputs
gray_ctr,
// Inputs
inc_en, preload_en, preload_val, clk, global_async_reset
);
//==================
// Parameters
//==================
parameter SIZE = 4;
//==================
// Port declarations
//==================
output [SIZE-1:0] gray_ctr;
input inc_en;
input preload_en;
input [SIZE-1:0] preload_val;
input clk;
input global_async_reset; // Global asynchronous reset
//====================================================
// Reg, wire, integer, task, and function declarations
//====================================================
reg [SIZE-1:0] gray_plus_1, gray_ctr, bnext, bin;
integer i;
//=================
// Logic
//=================
always @(posedge clk or posedge global_async_reset)
gray_ctr <= #1 global_async_reset ? 0 :
preload_en ? preload_val :
inc_en ? gray_plus_1 :
gray_ctr;
// Calculate next gray code by:
// 1) Converting current gray counter value to binary
// 2) Incrementing the binary value
// 3) Converting the incremented binary value to gray code
always @(gray_ctr or inc_en) begin
for (i=0; i<SIZE; i=i+1)
bin[i] = ^(gray_ctr >> i);
bnext = bin + 1;
gray_plus_1 = (bnext>>1) ^ bnext;
end
endmodule
Article: 61014
Hi All,
XILINX Sparten2e - ISE5.1i
Is is possible to created a LOC'd IO connection for signals internal to a
VHDL module?
I've created a VHDL Module that has some normal port IO, however it also
contains some signals that are specific only to the module. These signals
need to be routed to FPGA pins - and therefore I'd like a LOC constraint on
them.
If I declare these signals in the entity port desciption, then just apply
the LOC attribute, the signals are still 'visible' on the module symbol.
They do not need to be. So can I internally LOC these signals? Hope that
makes sense. Here's an example with some VHDL of what I'm trying to do.
The input is dataIn - (Hopefully) LOC'd to pin 12. It's buffered, then
connected to a synchronizer (just a double flip flop). The only 'visible'
IO is dataOut and clk.
When I try this XST sees dataIn as unconnected, so ties it to ground. Then
during translate, it get's all upset because the IBUF is drived from the
IPAD, but is also tied :-( What's the official way of doing this?
Any help would really make my life A LOT easier. Cheers
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
library UNISIM;
use UNISIM.VComponents.all;
entity interface is
Port ( clk : in std_logic;
dataOut : out std_logic);
end interface;
architecture Structural of interface is
component IBUF
port ( O : out std_logic;
I : in std_logic );
end component;
component SYNC
port ( dataIn : in std_logic;
dataOut : out std_logic;
clk : in std_logic );
end component;
attribute box_type : string;
attribute box_type of BUFG : component is "black_box";
attribute LOC : string;
attribute LOC of dataBuf : label is "P12";
signal dataIn : std_logic;
signal dataIn_b : std_logic;
begin
------------
-- Buffer --
------------
dataBuf : IBUF
port map ( I => dataIn,
O => dataIn_b);
----------------
-- Syncronize --
----------------
dataSync : SYNC
port map ( dataIn => dataIn_b,
dataOut => dataOut,
clk => clk);
end Structural;
Article: 61015It's interesting you say this. I have my own domain name which I use for private email but I would never post the email address on Usenet (even with a NOSPAM thing in it). You can use filter software to put things into different folders. For example, when registering on various corporate web pages, I often use newly generated emails: robert-analogdevices@mydomain.com robert-xilinx@mydomain.com When mail comes from those sites, it is placed into my folders "Analog Devices" or "Xilinx". If I start getting spam on one, I know who sold the database! And, it does a much better job at keeping my real email address clean (which has been clean for almost four years now). For usenet, you can see I signed up using a different email address on Yahoo. Jake "Mark" <markp100@hotmail.com> wrote in message news:<3HUcb.124132$bo1.76644@news-server.bigpond.net.au>... > Get your own domain name (register privately with no info about you > revealed) and email addresses in your private domain which you can easily > control. I did it a couple of years ago now and got an address for me and > one each for the family. Spam blocking software can be included, web mail > access is available, and you can switch ISP's at any time and be independent > of their spam-ridden email systems. Web hosting is also there if you need > it.Article: 61016
I guess I'm doing a lousy job of explaining what I'm looking for. The example I provided is hypothetical. Of course a frame buffer approach would be preferred and not too expensive to implement. No question about it. That's a no brainer. I know how to do that (Bresenham). In fact, I am doing that on a current project. But, that's not what I'm looking for. I'm looking for are algorithms that can render graphic primitives from real time screen x,y counter data (as well as the corresponding primitive parameters). Example: Draw a line, 1 pixel wide, at a 32 degree angle, from screen edge to screen edge. The input data would be real-time screen x and y coordinates as the pixels are being painted on screen. On a clock-by-clock basis you get to decide whether or not the pixel in question should be video or a white dot for your line. If this were a vertical or horizontal line (or 45 degrees, actually) it's a simple comparison: Vertical line: if x is equal to desired x position, light the pixel Horizontal line: if y is equal to the desired y position, light the pixel Diagonal line: if x and y are equal to a dedicated line x,y counter values, light the pixel. Line length is easily handled by means of limit registers. All of this happens in real time, without using any frame buffers whatsoever and with relatively minimal hardware resources (very small FPGA will do the job nicely). You could probably do arbitrary-angle diagonal lines in real time by simply having an algoritm increment/decrement a set of line x,y counters. Inputs would be screen pixel x,y coordinates and line parameters. That's one algorithm I'm interested in learning about. I'm working on my own, but if there's something out there I should consider I don't mind stopping wheel re-invention cold in its tracks. Drawing circular arcs might take a similar approach, but it would be a bit (or a lot) more complex. Maybe a LUT would be used to translate the graphic primitive's x,y counters into a circular arc. Of course, for a circle you have to deal with two or more points per scan line. Things get a bit more interesting if you need to add width to the graphic primitives. I hope I did a better job on this post. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:av28nv4njnt0ps2c23qoipe2nm1s5s98c9@4ax.com... > On Fri, 26 Sep 2003 07:15:44 GMT, "Martin Euredjian" > <0_0_0_0_@pacbell.net> wrote: > > >"Bob Feng" wrote: > >> Your comments after your question do not make sense to me. > > > >You are thinking computers. I'm thinking video. > > > >Here's one possible scenario. You are required to overlay graphics > >(primitives: lines, circles, etc.) and text onto an incoming video feed, > >which is then output in the same format. The allowable input to output > >delay is in the order of just a few clocks --if that much at all-- not > >frames, not lines, a few clocks at best. > > > > >Frame buffers are out of the question, of course. > > I don't see how this follows from your constraints. > > You say that the input to output video delay is at most a few clocks, > however you don't indicate that this constraint applies to the > overlay, e.g. the overlay could come from a frame buffer and then be > combined with the incoming video using some low latency method (either > digital or analog, using e.g. the analog switch method you mentioned). > You would need to genlock the FPGA generated video to the incoming > video, but that's not too hard. > > >In addition to this, due > >to cost constraints, you are not allowed to have rendering memory for the > >graphics overlay. You, therefore, must render text and graphics on the fly, > >in real time, as the signal flows through. > > I would expect that the cost of a cheap FPGA + cheap memory + simple > design would be much less than the cost of a larger FPGA + complex > design. > (Actually, I think the cost of the ram will be less than the cost of > fitting the heatsink you'll need if you don't have a ram. :) > > IOW, due to cost constraints, you should have rendering memory for the > graphics overlay. Of course, you'll need to do a detailed costing to > be sure, but I'd be surprised if the version with ram doesn't end up > being cheaper and get to market sooner. > > Note that larger FPGAs may be able to hold the frame buffer in > internal ram (but this depends on your resolution and pixel depth). > > Regards, > Allan.Article: 61017
MM wrote: > I don't think the netlist is valid. With D and CE both tied to VCC the flop > reverts to '1' on every clock regardless of my clk_ena signal. Your description says outf is low for reset, high otherwise. The only way to get a low with that description is to reset and immediately disble the clock. -- Mike TreselerArticle: 61018
jaideep wrote: > Jan Panteltje <panteltjeNSOAPM@yahoo.com> wrote in message news:<1064411674.535376@evisp-news-01.ops.asmr-01.energis-idc.net>... > >>What more can I say: I lost yahoo now. >>That virus searches Usenet for email addresses, and then sends >>thousands of times that microft fix with the worm. > > > Hi, > > I am also facing the same problem.Is there a fix to avoid this? > The normal fix is to replace your From email address with a munged or fake one, something like mine. At least with Mozilla/Netscape, that is easy to do; just create a new email account with a fake return address. If you do that, you normally should include a brief message at the bottom in your signature indicating that your email address is faked. It is unfortunate that things have come to this. -- My real email is akamail.com@dclark (or something like that).Article: 61019
"Vinh Pham" wrote: > You've got quite a set of challenging constraints there. So you're saying > an FPGA is cheaper than using a frame buffer and a micro-controller? Well, yes. I have to process half a billion pixels per second. Kinda hard to do with a microprocessor. > Another thing to think about is you'll need memory for each drawing > primitive in your overlay graphics, which might be a problem if you're going > to have a lot of primitives. I'm looking for an approach that would essentially evaluate equations for these primitives in real time. Therefore, no storage other than a few registes and counters would be required. It's relatively easy if you go to first principles, but probably not very efficient hardware-wise. I mean, look at Bresenham when compared to evaluating the equation of a line in real time. > By the way, how are you planning to sync to the incoming video > signal? That's easy. We call it "genlock", for "(sync) generator lock". A PLL does it. In the old days you had to design your own. Today there are many very nice canned solutions. > Well if you pull this off, it'll be quite impressive. Please let us know of > your progress. It's nothing to warrant being impressed. Seriously. It's just a matter of implementation. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 61020
Hello, Thanks for everybody. Seems, that Flip-flops would be the best solution. Yes, Aldec gave me a warning, but ... nothing to do with it.. :) Becouse "X" will be "0" or "1" in real, so I simply shifted testable "Dat" signal, adjusted a freequency to be repeated of Clock, and it worked. Other partitial solution of this problem - to make "And" operation with "X" and the same "Dat" signal after a short delay: "X and 0 = 0". But it will work only with negative "Dat" edge. For positive, "X or 1 = 1", will work too. But no chanse to find a way, how to force to work for both edges... :) /Vakaras/Article: 61021
OK, so how should I describe a D flip-flop with a synchronous reset and a clock enable with the D input tied to VCC? /Mikhail "Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message news:3F746BA9.20409@flukenetworks.com... > MM wrote: > > > I don't think the netlist is valid. With D and CE both tied to VCC the flop > > reverts to '1' on every clock regardless of my clk_ena signal. > > Your description says outf is low for reset, high otherwise. > The only way to get a low with that description > is to reset and immediately disble the clock. > > -- Mike Treseler >Article: 61022
Martin Euredjian wrote: > "Bob Feng" wrote: > >>Your comments after your question do not make sense to me. > > > You are thinking computers. I'm thinking video. > > Here's one possible scenario. You are required to overlay graphics > (primitives: lines, circles, etc.) and text onto an incoming video feed, > which is then output in the same format. The allowable input to output > delay is in the order of just a few clocks --if that much at all-- not > frames, not lines, a few clocks at best. > > Frame buffers are out of the question, of course. In addition to this, due > to cost constraints, you are not allowed to have rendering memory for the > graphics overlay. You, therefore, must render text and graphics on the fly, > in real time, as the signal flows through. > > Text and horizontal/vertical lines are pretty easy to deal with. You start > getting into circles and rotated lines or polygons and it gets interesting > real fast. In contrast to this, rendering these primitives to a frame > buffer (in a "traditional" computer-type application) is a no-brainer. > > >>Usaually a frame buffer is where you render. And then it goes through a > > DAC > >>and several video timing control units and reaches a CRT via a VGA or 13w3 >>connector. > > > So, in the above context, nothing goes through a DAC. The video feed > (assume analog) simply goes through some analog switches that, under FPGA > control, select, on a pixel-by-pixel basis, from among the incoming video > signal and a set of pre-established analog values (say white, to keep it > simple). > > > Hope this example clarifies it for you. > A frame buffer is simply a huge LUT(sort of) in which every pixel is corresponding to the one on the screen. The reason to have it is simply because of the huge effort to generate them in the front end. Bypassing the frame buffer means you need to have some fast algorithm to do some fast drawing. Correct? If you only do lines or individual pixels, I agree with you they are simple. You may also get away with circles or ovels. But for real graphics(I am talking about geometry+rasterization+texture), you have no way to do so. Circles and Ovels may be done via LUT. But your VTC design in FPGA maybe chanllenge. It should be fun though. ---BobArticle: 61023
"Chris Ebeling" <christopher.ebeling@xilinx.com> wrote in message news:3F7463B8.9687C89F@xilinx.com... > Mikhail, > Your last statement suggests a solution. > Have you tried creating signal and assigning that to one outside of the process? > > I this may (or may not) work. Tried, it doesn't work. > If you absolutely want some particular interconnect configuration of a Xilinx > Basic Element you can always instantiate any component in the the unisim library > > (unisim_VCOMP.vhd) FDRE in this case I would like to avoid this. > I'll also just mention XST implementation is logically correct even if it wasn't > what > you wanted. So, is there a way to describe what I want in VHDL so that XST will understand it? /MikhailArticle: 61024
A frame buffer is simply a huge LUT(sort of) in which every pixel is corresponding to the one on the screen. The reason to have it is simply because of the huge effort to generate them in the front end. Bypassing the frame buffer means you need to have some fast algorithm to do some fast drawing. Correct? If you only do lines or individual pixels, I agree with you they are simple. You may also get away with circles or ovels. But for real graphics(I am talking about geometry+rasterization+texture), you have no way to do so. Circles and Ovels may be done via LUT. But your VTC design in FPGA maybe chanllenge. It should be fun though. ---Bob "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:AIRcb.6331$0K3.502@newssvr27.news.prodigy.com... > "Bob Feng" wrote: > > Your comments after your question do not make sense to me. > > You are thinking computers. I'm thinking video. > > Here's one possible scenario. You are required to overlay graphics > (primitives: lines, circles, etc.) and text onto an incoming video feed, > which is then output in the same format. The allowable input to output > delay is in the order of just a few clocks --if that much at all-- not > frames, not lines, a few clocks at best. > > Frame buffers are out of the question, of course. In addition to this, due > to cost constraints, you are not allowed to have rendering memory for the > graphics overlay. You, therefore, must render text and graphics on the fly, > in real time, as the signal flows through. > > Text and horizontal/vertical lines are pretty easy to deal with. You start > getting into circles and rotated lines or polygons and it gets interesting > real fast. In contrast to this, rendering these primitives to a frame > buffer (in a "traditional" computer-type application) is a no-brainer. > > > Usaually a frame buffer is where you render. And then it goes through a > DAC > > and several video timing control units and reaches a CRT via a VGA or 13w3 > > connector. > > So, in the above context, nothing goes through a DAC. The video feed > (assume analog) simply goes through some analog switches that, under FPGA > control, select, on a pixel-by-pixel basis, from among the incoming video > signal and a set of pre-established analog values (say white, to keep it > simple). > > > Hope this example clarifies it for you. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Martin Euredjian > > To send private email: > 0_0_0_0_@pacbell.net > where > "0_0_0_0_" = "martineu" > >
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