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
Allan Herriman wrote > BTW, I see a significant speedup for large designs in Synplify if I > use the syn_hier attribute, which stops optimisations across module > boundaries. How big a speedup? I have wondered about this but never had an opportunity to measure it on truly large designs. Presumably the gain increases as the design size goes up. When syn_hier is asserted I would expect compilation time to be linear with design size. Without this attribute, is compilation time quadratic with size, or worse? If the company coding style include flops at the exit of all logic blocks I would not expect syn_hier to have much effect, though this style can be pretty hard to enforce for the control logic part of an application. Maybe Ken McElvain, or another Synplicity expert, can comment?Article: 40451
Hello,
I have a question for anyone out there familiar with Xilinx FPGA design. I am using Xilinx ISE and during the design rule check of the place & route (after writing out the verilog netlists and sdf files for post-route simulation), I get messages like the following:
WARNING: DesignRules: 372 - Netcheck: Gated clock: Clock net fsync1/CPUINTERFACE_0/N_115_inferred_clock is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop.
I have code like the following to generate my write strobes.
--------------
-- cut out library for brevity
entity CPUWRTGEN is
port
(RST :in std_logic;
CPU_ADDR :in std_logic_vector (10 downto 0);
WRT :out std_logic_vector (30 downto 0);
end CPUWRTGEN;
architecture BEHAVIOR of CPUWRTGEN is
signal CPU_ADDR_INT : integer range 0 to 63;
begin
CPU_ADDR_INT <= conv_integer(CPU_ADDR(5 downto 0));
process(CPU_ADDR, CPU_ADDR_INT)
begin
for I in 39 downto 9 loop
if CPU_ADDR (10 downto 6) = "01000" and CPU_ADDR_INT = I then
WRT(I-9) <= '0';
else
WRT(I-9) <= '1';
end if;
end loop;
end if;
end process;
end BEHAVIOR;
-----------------
I suspect this is the reason for the inferred clock since there is not clk controlling the write strobes.
How do I remedy the controlling the loading of the date into the flip-flop via the CE pin?
--
Salman Sheikh
NASA/GSFC Code 564
Greenbelt, MD 20771
301-286-3763 301-286-0220 (fax)
Article: 40452Ray gave an excellent detailed description. Here is the more simplistic one: Using a phase acumulator and a 50 MHz clock, you will achieve an average frequency or average on-time with extremely fine resolution, as fine as you want, determined only by the length of the accumulator. But not every on-time will be the same. You have excellent control over the average on-time, but since each on-time will be an integer multiple of 20 ns ( 50 MHz! ), the individual on-times will "dance around" to make your desired high-precision average. The output analog filter will average this all out. Hope this helps. Peter Alfke "F. Modderkolk" wrote: > Maybe I don't quit understand the working of the fpga, so explain me > whem I'm wrong. > I want to give you give you an example why my resolution needs to be > so high. > When I'm switching the fets with 300 kHz and I can switch my output > with 300MHz, the following is possible. Let's say the duty cycle of > my pulse is 40% ( it's always less than 50%). When I switch with 300 > kHz, one period is 3,33333 us. the next frequncy I can create at my > output = 1/300k + 1/300M = 3,33666 us. That is a frequency of > 299,700kHz. That is a difference of 300Hz. Such a difference means at > the output of the power supply a change of current of 0.2A. This is > because the working frequency is very small. I hope I made clear why I > need the high frequency. > > Ray Andraka <ray@andraka.com> wrote in message news:<3C862BFA.6BD14523@andraka.com>... > > See my post to your previous post. Knowing now what you are doing, I am > > sure you can get away with a much slower clock. Jitter is not likely to > > be much of a problem in this application. If, for example, you use a 10 > > MHz clock and a 32 bit accumulator you get a frequency resolution of 0.002 > > Hz with jitter no greater than 100ns (1 cycle of the master clock). Your > > master clock determines the amount of jitter and the maximum output > > frequency (Fclk/2). Resolution is determined just by the number of bits. > >Article: 40453
Nicholas Weaver wrote: > > (Note followup) > > I'm proud to announce the availability of a free, high performance > (1.3 Gbps in a Spartan II-100), and compact (<800 CLB slices), > Rijndael/AES encryption core optimized for Virtex family FPGAs from > Xilinx. It is fully key agile, uses 128b keys, and has a 5 stage > pipeline. It is currently only available as a Foundation 4.1 > schematic. > > It is available from http://www.cs.berkeley.edu/~nweaver/rijndael/ Are there other implementations of Rijndael in hardware? (If so, I'll add them to www.rijndael.com/implementations.html.) --Mike AmlingArticle: 40454
"Michael Amling" <spambad@nospam.com> wrote in message news:3C878A3B.5E5C8DC1@nospam.com... > Are there other implementations of Rijndael in hardware? (If so, I'll > add them to www.rijndael.com/implementations.html.) > > --Mike Amling Hi Mike, there are many in both FPGA and in ASICS. http://www.heliontech.com/downloads/aes_asic_helioncore.pdf http://www.realtime-info.be/vpr/layout/display/pr.asp?PRID=2298 I am amazed at some of the speeds, the support for three key sizes and support for all modes of operation. If I get time, I'll post more links. HTH, Flip -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 40455
Run an IBIS simulation. Austin Nahum Barnea wrote: > Hi. > I would like to use virtex 2 OBUF_LVDCI_DV2_18 output pad > in order to drive a clock signal of 250 MHz. > > Is it possible ? > Will I get good clock shape on the board ? > How can I verify that I will get good clock shape on the board ? > > ThankX , > Nahum.Article: 40456
Cindy, The same as any other pin in the Abs Max section of the data sheet. Austin Cindy wrote: > Is there is absolute maximum voltage specified for the DXP and DXN pins? > > Thanks!Article: 40457
*Sigh*
I've really got to put together the FAQ on this one...
In your architecture declarations:
component RAMB4_S1_S1
--synthesis translate_off
generic(
TimingChecksOn : BOOLEAN := FALSE);
--synthesis translate_on
port(
DIA : in std_logic_vector(0 downto 0);
DIB : in std_logic_vector(0 downto 0);
ENA : in std_ulogic;
ENB : in std_ulogic;
WEA : in std_ulogic;
WEB : in std_ulogic;
RSTA : in std_ulogic;
RSTB : in std_ulogic;
CLKA : in std_ulogic;
CLKB : in std_ulogic;
ADDRA : in std_logic_vector(11 downto 0);
ADDRB : in std_logic_vector(11 downto 0);
DOA : out std_logic_vector(0 downto 0);
DOB : out std_logic_vector(0 downto 0));
end component;
attribute syn_black_box of RAMB4_S1_S1:component is TRUE;
Then in the architecture body:
MEM: RAMB4_S1_S1 port map(
DIA => wdata(0 to 0),
DIB => "0",
ENA => '1',
ENB => '1',
WEA => '1',
WEB => '0',
RSTA => '0',
RSTB => '0',
CLKA => clk,
CLKB => clk,
ADDRA =>waddr,
ADDRB => raddr,
DOA => open,
DOB => rdata(0 to 0));
Your signals may vary.
Theron Hicks wrote:
> Ray,
> How does one instantiate the BRAM directly? I am using VHDL if that has any
> impact on the question. Can you give me a code snippet as an example?
>
> Thanks,
> Theron Hicks
>
> Ray Andraka wrote:
>
> > Personally, I prefer to instantiate the BRAM primitives directly rather than
> > using the coregen. That way you lose the extra layer of abstraction, that in
> > this case does little more than make it harder to simulate. If you do use the
> > BRAM generator and select register inputs under the design options, then putting
> > a small combinatorial mux in front of it should put the mux with the registers
> > (at least the last layer of the mux if it is more than 2 inputs). If you are
> > instantiating the BRAMs, then your muxes should be registered. One note of
> > caution: if you are trying to get the most speed, keep in mind that you want the
> > registers as close as possible to the BRAM. Putting muxes with those registers
> > is going to tend to congest the routing there, which may slow your critical BRAM
> > connections. For that matter, it also helps to keep the width of the BRAM
> > relatively small so you don't have a ton of data lines going in and out
> > (especially for dual ports with both ports used in both directions).
> >
> > "H.L" wrote:
> >
> > > Hello Ray,
> > > thanks a lot your post clarified things.
> > > Xilinx Core Generator cant put additional register on the EN signal, so the
> > > only thing is to instantiate a D flip-flop and put it in the right place?
> > >
> > > Regarding my project I have to arbitrate the access in 3 BRAMs (registered
> > > for the reason described above) so I think I must use a MUX_BUS from the
> > > CORE GENERATOR (one MUX_BUS for each BRAM). I will use 3 MUX_BUS with 3
> > > input 41-bit buses (32 for the data, 7 for the address, 2 bits for EN,WE).
> > > If I use non-registered MUXs I think is not good for the following reasons:
> > > 1) The timing analysis will not include them in the period calculation so I
> > > will not be able to see if my FPGA meets the timing constraints
> > > 2) Combinatorial logic in the BRAM paths. Here is my second question, as I
> > > said before I am going to use registered BRAMs do you think that these
> > > registers are capable to cope with the inserted MUXs' combinatorial logic? I
> > > don't know if these MUXs I'll use can be described as "large" or "small"
> > > combinatorial logic.
> > >
> > > So the right thing to do is to use registered MUXs (LUT based only as Xilinx
> > > says)?
> > >
> > > Best Regards,
> > > Harris
> > >
> > > "Ray Andraka" <ray@andraka.com> wrote in message
> > > news:3C824FD0.71540235@andraka.com...
> > > >
> > > >
> > > > "H.L" wrote:
> > > >
> > > > > Hi Ray,
> > > > > I have seen these tips written by you many times in this group. I have
> > > them
> > > > > always as a guide but I want to see if I understand them right. Please
> > > > > correct me where I am wrong:
> > > > >
> > > > > 1) The need for additional registers in DATA_IN and ADDR signals.
> > > > > In BRAMs the EN and WE signals have long set-up times thats why we need
> > > to
> > > > > register the data_in and addr of the BRAM, in this way the addr and
> > > data_in
> > > > > signals have a clock period delay.As EN,WE reach the BRAM 1 clock period
> > > > > earlier (at 155MHz clock speed that means about 6 ns) the setup-time
> > > for
> > > > > these signals is not violated resulting BRAM to be in the operation mode
> > > we
> > > > > wish (read or write) the moment addr and data_in arrive.
> > > >
> > > > If you look at the data sheet, there are fairly long set-up times on all
> > > the
> > > > BRAM inputs. Routing to the BRAMs also adds to the delay, as does any
> > > > combinatorial logic on these inputs. The idea of putting registers on the
> > > > inputs (which includes the EN and WE inputs) is to minimize the amount of
> > > delay
> > > > added externally to these signals. Your understanding is a bit incorrect,
> > > as
> > > > what you are suggesting is delaying signals to allow a long combinatorial
> > > > delay. That is dangerous, because there is no guarantee on the minimum
> > > delay.
> > > > Instead, what I am suggesting is to remove as much of the delay as
> > > possible
> > > > between the registers driving the BRAM inputs and the BRAM inputs, which
> > > meahs
> > > > avoiding combinatorial logic on these paths, minimizing the fanout of
> > > these
> > > > signals, and physically locating the registers close to the BRAMs.
> > > >
> > > > >
> > > > > 2) The need for floorplanning
> > > > > Xilinx software tool maybe has put the additional registers far from the
> > > > > BRAMs, if this is the case we must manual place them near the BRAM to
> > > > > decrease the propagation delay of the signals.
> > > >
> > > > That is correct. Routing in FPGAs is not just wire, it also consists of
> > > > switches which add to the propagation delay of signals on the connections
> > > > between logic. Manually placing the registers near the BRAM helps to
> > > minimize
> > > > the added delay.
> > > >
> > > > >
> > > > > 3) Tying the WE,EN inputs and contol access through the address when
> > > working
> > > > > at high speeds.
> > > > > Do you mean to keep WE,EN high all the time and when we wish not to use
> > > the
> > > > > BRAMs to write dummy data in some (or just one) specified addresses (or
> > > > > address) reserved for this reason?
> > > >
> > > > That is correct. The set up times for EN and WE are nearly twice the
> > > set-up
> > > > times for address and data, so if we can eliminate these from the equation
> > > we
> > > > can run at a higher clock rate. They can be eliminated by always writing,
> > > but
> > > > directing the writes of invalid data to locations where it does not affect
> > > the
> > > > operation of the design. In the case of FIFOs, you can just park the
> > > write
> > > > address until you have a valid write, since you are presumably not reading
> > > that
> > > > data until it is valid.
> > > >
> > > > >
> > > > >
> > > > > Also I have another one question about BRAMs, Xilinx says that BRAMs'
> > > DATA
> > > > > OUT are already registered. In Xilinx Floorplanner I believe this
> > > register
> > > > > is "inside" the BLKRAM box so no manual floorplanning for the output is
> > > > > needed. You need to manual floorplan (in the same way you do for the
> > > inputs)
> > > > > only if you choose to add an additional output register, correct?
> > > >
> > > > That is correct, the BRAM acts as though it is registered, although I
> > > believe
> > > > the actual implementation has the register on the address, not on the
> > > memroy
> > > > outputs. In any event, the clock to out time is long compared to that of
> > > the
> > > > CLB flip-flops. The system clock rate can be increased by putting an
> > > additional
> > > > register on the BRAM data outputs and placing that register physically
> > > close to
> > > > the BRAM (that register should have no combinatorial logic in front of
> > > it).
> > > >
> > > > >
> > > > >
> > > > > I really appreciate your help.
> > > > >
> > > > > Best Regards,
> > > > > Harris
> > > > >
> > > > > "Ray Andraka" <ray@andraka.com> wrote in message
> > > > > news:3C7FD73D.F6A3109A@andraka.com...
> > > > > > VirtexE BRAMs can be written at 155MHz in any speed grade. To do so,
> > > you
> > > > > will
> > > > > > likely have to put registers near to and with no logic between them
> > > and
> > > > > the
> > > > > > BRAMs. Watch the loading too, routing to more than 1 BRAM for each
> > > > > register may
> > > > > > cause you some heartburn. At higher speeds, you probably should also
> > > > > consider
> > > > > > tying the WE, and ENA inputs active and controlling your access
> > > through
> > > > > the
> > > > > > address registers instead. You'll also need to floorplan the
> > > registers to
> > > > > make
> > > > > > sure they are located physically close to the BRAMs.
> > > > > >
> > > > > > "H.L" wrote:
> > > > > >
> > > > > > > Hi Peter, thanks for your reply
> > > > > > > I was confident of this method's effectiveness but now I am worried
> > > :))
> > > > > . I
> > > > > > > have already done a timing analysis in the paper and also the
> > > simulation
> > > > > > > waveforms seem promising.
> > > > > > > I didnt understand what do you mean when telling me that one of my
> > > words
> > > > > > > arrives early and the other one late. The transmitter sends to my
> > > FPGA
> > > > > an
> > > > > > > external clock (thats the 155MHz clock), a valid signal (1 bit
> > > > > indicating
> > > > > > > the transmission time period) and of course the 16-bit words that I
> > > have
> > > > > to
> > > > > > > store. Every clock period (~6 ns) I have available in my ports one
> > > > > 16-bit
> > > > > > > word, I register two sequential words from the in port to a 32-bit
> > > > > register
> > > > > > > (31->16 the first incoming word, 15->0 the second one). Then , in
> > > > > another
> > > > > > > 32-bit register I register (2 nd time) the 32-bit word I just "made"
> > > > > which
> > > > > > > are the BRAM data_in. All the above operations are in a process that
> > > has
> > > > > in
> > > > > > > its sensitivity list the 155 clock. I write to the BRAM at 77MHz
> > > using
> > > > > the
> > > > > > > incoming clock divide by 2 using a DLL. BRAM input signals are
> > > assigned
> > > > > in
> > > > > > > the falling edge of the 77MHz clock so as to be before the rising
> > > edge
> > > > > (of
> > > > > > > the same clock) where the BRAM samples them. The write operations
> > > are in
> > > > > > > another process with the slow clock in its sensitivity list.
> > > > > > > The timing waveforms of the simulation are the same with the timing
> > > > > analysis
> > > > > > > in paper but does this is a valid hardware design technique?
> > > > > > > Thanks for your time and help!
> > > > > > >
> > > > > > > Best Regards,
> > > > > > > Harris
> > > > > > >
> > > > > > > p.s: thats a small part of my design. I use DLL because other parts
> > > need
> > > > > > > them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155
> > > MHz
> > > > > and I
> > > > > > > got many timing errors (floorplanning managed to reduce them but
> > > still
> > > > > lot
> > > > > > > of work to be done)
> > > > > > >
> > > > > > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message
> > > > > > > news:3C7E621F.1E77A244@xilinx.com...
> > > > > > > > I suggest you grab pencil and paper and do a clock-by-clock timing
> > > > > > > analysis. You
> > > > > > > > will find that your clock-speed reduction buys you nothing, unless
> > > you
> > > > > > > also
> > > > > > > > double-buffer the data.
> > > > > > > > One of your words arrives nice and early, the other one late.
> > > However
> > > > > you
> > > > > > > clock
> > > > > > > > the BRAM, one of the two words has the same old short set-up
> > > time...
> > > > > > > > Double-buffering would help. But Ray has mentioned some neat
> > > tricks to
> > > > > > > avoid the
> > > > > > > > long set-up time of the control inputs.
> > > > > > > >
> > > > > > > > I will get back with more constructive notes. "Gotta run"
> > > > > > > >
> > > > > > > > Peter Alfke
> > > > > > > > ===================
> > > > > > > > "H.L" wrote:
> > > > > > > >
> > > > > > > > > Hello all,
> > > > > > > > >
> > > > > > > > > I have a module that accepts 16 bit words at 155MHz and I want
> > > to
> > > > > store
> > > > > > > then
> > > > > > > > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA)
> > > to
> > > > > > > divide by
> > > > > > > > > 2 the 155MHz clock as this frequency seems to be pretty high to
> > > > > write in
> > > > > > > the
> > > > > > > > > BRAM. So far I think 2 processes are enough to do my job, one
> > > > > operating
> > > > > > > @
> > > > > > > > > 155MHz to accept the 16-bit data and store them in a 32-bit
> > > register
> > > > > and
> > > > > > > the
> > > > > > > > > another one @ 75MHz to write the content of the 32-bit register
> > > in
> > > > > the
> > > > > > > BRAM.
> > > > > > > > > I am thinking to assign the BRAM's signals
> > > > > > > (ENABLE,WRITE,ADDRESS,DATA_IN) in
> > > > > > > > > the falling edge of the 75MHz clock, the main reason for this is
> > > the
> > > > > > > setup
> > > > > > > > > time of the BRAMs signals (in this way the address,data are 6 ns
> > > > > before
> > > > > > > next
> > > > > > > > > rising edge of the clock where BRAM samples its inputs). My
> > > question
> > > > > now
> > > > > > > :)
> > > > > > > > > , if one process uses the falling edge of one clock does this
> > > causes
> > > > > > > > > problems to other processes in the design , e.g to processes
> > > that
> > > > > use a
> > > > > > > > > different clock or to processes using the rising edge of the
> > > same
> > > > > > > clock?
> > > > > > > > >
> > > > > > > > > Best Regards,
> > > > > > > > > Harris.
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > --Ray Andraka, P.E.
> > > > > > President, the Andraka Consulting Group, Inc.
> > > > > > 401/884-7930 Fax 401/884-7950
> > > > > > email ray@andraka.com
> > > > > > http://www.andraka.com
> > > > > >
> > > > > > "They that give up essential liberty to obtain a little
> > > > > > temporary safety deserve neither liberty nor safety."
> > > > > > -Benjamin Franklin, 1759
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > --Ray Andraka, P.E.
> > > > President, the Andraka Consulting Group, Inc.
> > > > 401/884-7930 Fax 401/884-7950
> > > > email ray@andraka.com
> > > > http://www.andraka.com
> > > >
> > > > "They that give up essential liberty to obtain a little
> > > > temporary safety deserve neither liberty nor safety."
> > > > -Benjamin Franklin, 1759
> > > >
> > > >
Article: 40458Hi All, I am using ISE 4.1i and ModelSim PE for Verilog. I try to simulate one sub-module of my design. I use "Generating Post Place and Route Simulation Model" to generate Verilog file for ModelSim PE. I always lost some ports in that file. How do I keep those ports even I did not use them in that sub-module ? Any idea ? KennyArticle: 40459
Call your local Synplicity FAE. Synplify 7.1 is available in late Beta. Leon Qin wrote: > > Altera says that QuartusII 2.0 working with Synplify 7.1 ,but I can > only found ver 7.03 on SYNPLICITY website for download.Article: 40460
> > Look at the app notes: > > http://www.support.xilinx.com/xapp/xapp253.pdf > This appnote is not available any more. Maybe somebody has it and is willing to send it to me ? I also have trouble using VIRTEX-2 with DDR-SDRAM. Thanks Manfred Kraus newsreply@cesys.comArticle: 40461
I have 60 XC2V3000-4FF1152CES (still in original vacuum-pack), but I need
XC2V4000-FF1152CESs and XC2V6000-4FF1152CESs. If you have excess inventory
of the larger parts and want to sell them or trade them for the the smaller
ones, please contact me. We are in need of the larger parts ASAP and can't
deal with the long lead times.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 40462Thanks a lot Ray!!! I will try to instantiate the BRAM primitives according to your following post. Best Regards Harris "Ray Andraka" <ray@andraka.com> wrote in message news:3C86D04D.991FE2B8@andraka.com... > Personally, I prefer to instantiate the BRAM primitives directly rather than > using the coregen. That way you lose the extra layer of abstraction, that in > this case does little more than make it harder to simulate. If you do use the > BRAM generator and select register inputs under the design options, then putting > a small combinatorial mux in front of it should put the mux with the registers > (at least the last layer of the mux if it is more than 2 inputs). If you are > instantiating the BRAMs, then your muxes should be registered. One note of > caution: if you are trying to get the most speed, keep in mind that you want the > registers as close as possible to the BRAM. Putting muxes with those registers > is going to tend to congest the routing there, which may slow your critical BRAM > connections. For that matter, it also helps to keep the width of the BRAM > relatively small so you don't have a ton of data lines going in and out > (especially for dual ports with both ports used in both directions). > > "H.L" wrote: > > > Hello Ray, > > thanks a lot your post clarified things. > > Xilinx Core Generator cant put additional register on the EN signal, so the > > only thing is to instantiate a D flip-flop and put it in the right place? > > > > Regarding my project I have to arbitrate the access in 3 BRAMs (registered > > for the reason described above) so I think I must use a MUX_BUS from the > > CORE GENERATOR (one MUX_BUS for each BRAM). I will use 3 MUX_BUS with 3 > > input 41-bit buses (32 for the data, 7 for the address, 2 bits for EN,WE). > > If I use non-registered MUXs I think is not good for the following reasons: > > 1) The timing analysis will not include them in the period calculation so I > > will not be able to see if my FPGA meets the timing constraints > > 2) Combinatorial logic in the BRAM paths. Here is my second question, as I > > said before I am going to use registered BRAMs do you think that these > > registers are capable to cope with the inserted MUXs' combinatorial logic? I > > don't know if these MUXs I'll use can be described as "large" or "small" > > combinatorial logic. > > > > So the right thing to do is to use registered MUXs (LUT based only as Xilinx > > says)? > > > > Best Regards, > > Harris > > > > "Ray Andraka" <ray@andraka.com> wrote in message > > news:3C824FD0.71540235@andraka.com... > > > > > > > > > "H.L" wrote: > > > > > > > Hi Ray, > > > > I have seen these tips written by you many times in this group. I have > > them > > > > always as a guide but I want to see if I understand them right. Please > > > > correct me where I am wrong: > > > > > > > > 1) The need for additional registers in DATA_IN and ADDR signals. > > > > In BRAMs the EN and WE signals have long set-up times thats why we need > > to > > > > register the data_in and addr of the BRAM, in this way the addr and > > data_in > > > > signals have a clock period delay.As EN,WE reach the BRAM 1 clock period > > > > earlier (at 155MHz clock speed that means about 6 ns) the setup-time > > for > > > > these signals is not violated resulting BRAM to be in the operation mode > > we > > > > wish (read or write) the moment addr and data_in arrive. > > > > > > If you look at the data sheet, there are fairly long set-up times on all > > the > > > BRAM inputs. Routing to the BRAMs also adds to the delay, as does any > > > combinatorial logic on these inputs. The idea of putting registers on the > > > inputs (which includes the EN and WE inputs) is to minimize the amount of > > delay > > > added externally to these signals. Your understanding is a bit incorrect, > > as > > > what you are suggesting is delaying signals to allow a long combinatorial > > > delay. That is dangerous, because there is no guarantee on the minimum > > delay. > > > Instead, what I am suggesting is to remove as much of the delay as > > possible > > > between the registers driving the BRAM inputs and the BRAM inputs, which > > meahs > > > avoiding combinatorial logic on these paths, minimizing the fanout of > > these > > > signals, and physically locating the registers close to the BRAMs. > > > > > > > > > > > 2) The need for floorplanning > > > > Xilinx software tool maybe has put the additional registers far from the > > > > BRAMs, if this is the case we must manual place them near the BRAM to > > > > decrease the propagation delay of the signals. > > > > > > That is correct. Routing in FPGAs is not just wire, it also consists of > > > switches which add to the propagation delay of signals on the connections > > > between logic. Manually placing the registers near the BRAM helps to > > minimize > > > the added delay. > > > > > > > > > > > 3) Tying the WE,EN inputs and contol access through the address when > > working > > > > at high speeds. > > > > Do you mean to keep WE,EN high all the time and when we wish not to use > > the > > > > BRAMs to write dummy data in some (or just one) specified addresses (or > > > > address) reserved for this reason? > > > > > > That is correct. The set up times for EN and WE are nearly twice the > > set-up > > > times for address and data, so if we can eliminate these from the equation > > we > > > can run at a higher clock rate. They can be eliminated by always writing, > > but > > > directing the writes of invalid data to locations where it does not affect > > the > > > operation of the design. In the case of FIFOs, you can just park the > > write > > > address until you have a valid write, since you are presumably not reading > > that > > > data until it is valid. > > > > > > > > > > > > > > > Also I have another one question about BRAMs, Xilinx says that BRAMs' > > DATA > > > > OUT are already registered. In Xilinx Floorplanner I believe this > > register > > > > is "inside" the BLKRAM box so no manual floorplanning for the output is > > > > needed. You need to manual floorplan (in the same way you do for the > > inputs) > > > > only if you choose to add an additional output register, correct? > > > > > > That is correct, the BRAM acts as though it is registered, although I > > believe > > > the actual implementation has the register on the address, not on the > > memroy > > > outputs. In any event, the clock to out time is long compared to that of > > the > > > CLB flip-flops. The system clock rate can be increased by putting an > > additional > > > register on the BRAM data outputs and placing that register physically > > close to > > > the BRAM (that register should have no combinatorial logic in front of > > it). > > > > > > > > > > > > > > > I really appreciate your help. > > > > > > > > Best Regards, > > > > Harris > > > > > > > > "Ray Andraka" <ray@andraka.com> wrote in message > > > > news:3C7FD73D.F6A3109A@andraka.com... > > > > > VirtexE BRAMs can be written at 155MHz in any speed grade. To do so, > > you > > > > will > > > > > likely have to put registers near to and with no logic between them > > and > > > > the > > > > > BRAMs. Watch the loading too, routing to more than 1 BRAM for each > > > > register may > > > > > cause you some heartburn. At higher speeds, you probably should also > > > > consider > > > > > tying the WE, and ENA inputs active and controlling your access > > through > > > > the > > > > > address registers instead. You'll also need to floorplan the > > registers to > > > > make > > > > > sure they are located physically close to the BRAMs. > > > > > > > > > > "H.L" wrote: > > > > > > > > > > > Hi Peter, thanks for your reply > > > > > > I was confident of this method's effectiveness but now I am worried > > :)) > > > > . I > > > > > > have already done a timing analysis in the paper and also the > > simulation > > > > > > waveforms seem promising. > > > > > > I didnt understand what do you mean when telling me that one of my > > words > > > > > > arrives early and the other one late. The transmitter sends to my > > FPGA > > > > an > > > > > > external clock (thats the 155MHz clock), a valid signal (1 bit > > > > indicating > > > > > > the transmission time period) and of course the 16-bit words that I > > have > > > > to > > > > > > store. Every clock period (~6 ns) I have available in my ports one > > > > 16-bit > > > > > > word, I register two sequential words from the in port to a 32-bit > > > > register > > > > > > (31->16 the first incoming word, 15->0 the second one). Then , in > > > > another > > > > > > 32-bit register I register (2 nd time) the 32-bit word I just "made" > > > > which > > > > > > are the BRAM data_in. All the above operations are in a process that > > has > > > > in > > > > > > its sensitivity list the 155 clock. I write to the BRAM at 77MHz > > using > > > > the > > > > > > incoming clock divide by 2 using a DLL. BRAM input signals are > > assigned > > > > in > > > > > > the falling edge of the 77MHz clock so as to be before the rising > > edge > > > > (of > > > > > > the same clock) where the BRAM samples them. The write operations > > are in > > > > > > another process with the slow clock in its sensitivity list. > > > > > > The timing waveforms of the simulation are the same with the timing > > > > analysis > > > > > > in paper but does this is a valid hardware design technique? > > > > > > Thanks for your time and help! > > > > > > > > > > > > Best Regards, > > > > > > Harris > > > > > > > > > > > > p.s: thats a small part of my design. I use DLL because other parts > > need > > > > > > them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155 > > MHz > > > > and I > > > > > > got many timing errors (floorplanning managed to reduce them but > > still > > > > lot > > > > > > of work to be done) > > > > > > > > > > > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message > > > > > > news:3C7E621F.1E77A244@xilinx.com... > > > > > > > I suggest you grab pencil and paper and do a clock-by-clock timing > > > > > > analysis. You > > > > > > > will find that your clock-speed reduction buys you nothing, unless > > you > > > > > > also > > > > > > > double-buffer the data. > > > > > > > One of your words arrives nice and early, the other one late. > > However > > > > you > > > > > > clock > > > > > > > the BRAM, one of the two words has the same old short set-up > > time... > > > > > > > Double-buffering would help. But Ray has mentioned some neat > > tricks to > > > > > > avoid the > > > > > > > long set-up time of the control inputs. > > > > > > > > > > > > > > I will get back with more constructive notes. "Gotta run" > > > > > > > > > > > > > > Peter Alfke > > > > > > > =================== > > > > > > > "H.L" wrote: > > > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > > > > > I have a module that accepts 16 bit words at 155MHz and I want > > to > > > > store > > > > > > then > > > > > > > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA) > > to > > > > > > divide by > > > > > > > > 2 the 155MHz clock as this frequency seems to be pretty high to > > > > write in > > > > > > the > > > > > > > > BRAM. So far I think 2 processes are enough to do my job, one > > > > operating > > > > > > @ > > > > > > > > 155MHz to accept the 16-bit data and store them in a 32-bit > > register > > > > and > > > > > > the > > > > > > > > another one @ 75MHz to write the content of the 32-bit register > > in > > > > the > > > > > > BRAM. > > > > > > > > I am thinking to assign the BRAM's signals > > > > > > (ENABLE,WRITE,ADDRESS,DATA_IN) in > > > > > > > > the falling edge of the 75MHz clock, the main reason for this is > > the > > > > > > setup > > > > > > > > time of the BRAMs signals (in this way the address,data are 6 ns > > > > before > > > > > > next > > > > > > > > rising edge of the clock where BRAM samples its inputs). My > > question > > > > now > > > > > > :) > > > > > > > > , if one process uses the falling edge of one clock does this > > causes > > > > > > > > problems to other processes in the design , e.g to processes > > that > > > > use a > > > > > > > > different clock or to processes using the rising edge of the > > same > > > > > > clock? > > > > > > > > > > > > > > > > Best Regards, > > > > > > > > Harris. > > > > > > > > > > > > > > > > > -- > > > > > --Ray Andraka, P.E. > > > > > President, the Andraka Consulting Group, Inc. > > > > > 401/884-7930 Fax 401/884-7950 > > > > > email ray@andraka.com > > > > > http://www.andraka.com > > > > > > > > > > "They that give up essential liberty to obtain a little > > > > > temporary safety deserve neither liberty nor safety." > > > > > -Benjamin Franklin, 1759 > > > > > > > > > > > > > > > > -- > > > --Ray Andraka, P.E. > > > President, the Andraka Consulting Group, Inc. > > > 401/884-7930 Fax 401/884-7950 > > > email ray@andraka.com > > > http://www.andraka.com > > > > > > "They that give up essential liberty to obtain a little > > > temporary safety deserve neither liberty nor safety." > > > -Benjamin Franklin, 1759 > > > > > > >Article: 40463
"Salman Sheikh" <sheikh@pop500.gsfc.nasa.gov> schrieb im Newsbeitrag
news:20020307102855.29f702fc.sheikh@pop500.gsfc.nasa.gov...
> WARNING: DesignRules: 372 - Netcheck: Gated clock: Clock net
fsync1/CPUINTERFACE_0/N_115_inferred_clock is sourced by a combinatorial
pin. This is not good design practice. Use the CE pin to control the loading
of data into the flip-flop.
>
> I suspect this is the reason for the inferred clock since there is not clk
controlling the write strobes.
> How do I remedy the controlling the loading of the date into the flip-flop
via the CE pin?
process (clk)
begin
if clk='1' and clk'event then
if load='1' then
flipflip<=data;
end if;
end if;
end process;
This gives you a nice clock enable without gated clocks.
--
MfG
Falk
Article: 40464Try enabling the "Correlate Simulation Data to Input Design" switch form the simulation netlist options in ISE. That works sometimes but not all the time. If that does not work, you will need to modify your testbench (comment out those port connnections). If you were using VHDL, there is one other trick of compiling the architecture only, but that is not an option for Verilog. -- Brian Kenny wrote: > Hi All, > > I am using ISE 4.1i and ModelSim PE for Verilog. > I try to simulate one sub-module of my design. I use "Generating Post > Place and Route Simulation Model" to generate Verilog file for > ModelSim PE. > I always lost some ports in that file. How do I keep those ports even > I did not use them in that sub-module ? > > Any idea ? > > KennyArticle: 40465
On Wed, 06 Mar 2002 23:50:32 GMT, John_H <johnhandwork@mail.com> wrote: Yes, I can see why one would wonder why I would want to do such a thing. Imagine a series-connected string of nodes (up to 24), with a pair of back-to-back E1 transceivers in each node. Most of the data on the E1 link is repeated, but there is some add-drop activity in each node. The tough part is that nodes are added to each end, and removed or inserted in the middle, on a dynamic (in the order of once a day) basis. These nodes have no knowledge of where they are physically in the chain, and cannot be configured by an operator. Coming up with a mechanism to reliably maintain one master clock in this dynamic system is non-trivial. The thinking is that a democratic clock may be an easier thing to do then dealing with master management. >The telecom timing management tends to be a central timing standard with >the E1 signals deriving their timing from the reference. This distributed >scheme leaves clock management in one central node. When you cross >jurisdictions (e.g. France/England interface) you live with slips defined >at a maximum rate. > >What I don't understand (since you are deviating from this standard) is >what you gain by trying to "democratize" the independent timing elements. >This is such a non-standard approach to my telecom background and to my >timing system development in general that I can't make suggestions. > >What you're looking for, in effect, is to have three independent systems >(for instance) come to a compromise on a common frequency so you end up >with a very "symmetric" timing scheme? It would be soooo much easier if >you chose one element to be the timing master. (snip) =================================== Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.comArticle: 40466
A series-connected string of nodes could pass tthe timing from node to node to node down the chain. If you use good E1 parts, clock recovery is part of the silicon and conforms to ITU-T jitter transfer specifications which maintains clean phase jitter at higher frequencies by design. These things are made to be daisy-chained about once a kilometer on some very long runs. If you're dealing with bidirectional traffic, you just need to know if the node is an end node or not and loop back the timing that came down from the front of the nodes. A ring is a slightly different issue, but selecting one node as "master" is straightforward. Alternatively, one timing reference could be delivered to all 24 nodes as with the central timing scheme. Pretty standard telecom stuff applies nicely to non telecom applications. Otherwise, would you be using 23 different phase comparators on each of the 24 nodes for the democratic approach? Greg Neff wrote: > On Wed, 06 Mar 2002 23:50:32 GMT, John_H <johnhandwork@mail.com> > wrote: > > Yes, I can see why one would wonder why I would want to do such a > thing. Imagine a series-connected string of nodes (up to 24), with a > pair of back-to-back E1 transceivers in each node. Most of the data > on the E1 link is repeated, but there is some add-drop activity in > each node. > > The tough part is that nodes are added to each end, and removed or > inserted in the middle, on a dynamic (in the order of once a day) > basis. These nodes have no knowledge of where they are physically in > the chain, and cannot be configured by an operator. Coming up with a > mechanism to reliably maintain one master clock in this dynamic system > is non-trivial. The thinking is that a democratic clock may be an > easier thing to do then dealing with master management. > > >The telecom timing management tends to be a central timing standard with > >the E1 signals deriving their timing from the reference. This distributed > >scheme leaves clock management in one central node. When you cross > >jurisdictions (e.g. France/England interface) you live with slips defined > >at a maximum rate. > > > >What I don't understand (since you are deviating from this standard) is > >what you gain by trying to "democratize" the independent timing elements. > >This is such a non-standard approach to my telecom background and to my > >timing system development in general that I can't make suggestions. > > > >What you're looking for, in effect, is to have three independent systems > >(for instance) come to a compromise on a common frequency so you end up > >with a very "symmetric" timing scheme? It would be soooo much easier if > >you chose one element to be the timing master. > (snip) > > =================================== > Greg Neff > VP Engineering > *Microsym* Computers Inc. > greg@guesswhichwordgoeshere.comArticle: 40467
Hello Kenny, I believe that you are referring to MXE-II (5.5e) rather than MXE (5.5b) which is the question Cindy answered. To clarify, MXE-II has the following limitations on speed: < 40k lines is 40% the speed of PE 40k - 50k lines is 10% the speed of PE > 50k lines is 1% the speed of PE The numbers in Cindy's answer are for MXE. I hope this helps. Regards, KamalArticle: 40468
On Thu, 07 Mar 2002 06:10:09 GMT, allan_herriman.hates.spam@agilent.com (Allan Herriman) wrote: See my reply to John_H as to why we want to implement a democratic clock. I took a quick look at the parts you were kind enough to provide links to. One part has two clock inputs. The other has many clock inputs. The problem is that the PLL selects one of the inputs to be the reference. We would want a PLL that would accept three reference clocks simultaneously. The PLL output would be a function of all three clocks. One reference clock would be the local XO. The other two clocks would be recovered from the two E1 receivers. The output of the PLL would then provide the clock for both E1 transmitters. This is the general idea. We are trying to figure out if this idea will work reliably in practice, and would like to find any information that exists on this type of scheme. (snip) > >As the other posters have mentioned, a "democratic" approach to timing >is unusual, and (to me) doesn't make sense. > >Regarding the ITU-T specifications, I think you should look at the >SONET/SDH specs instead of the E1 ones. >Try: ITU-T G.707 (SDH) and the G.810 series (SDH timing). >Also GR-253 (SONET). > >Even the Network Time Protocol (RFC1305) that is used to synchronise >time of day clocks on computers has a hierarchy of timing sources. >But it might give you some ideas that will help you with your problem. >http://www.ietf.org/rfc/rfc1305.txt > >Oh, you should probably look at the datasheets for chips that are >designed for phone network timing, e.g. Zarlink (nee Mitel) MT90401 >http://products.zarlink.com/partfinder/prodprofile.cgi?device=1127 >or maybe this one from Semtech: >http://www.semtech.com/products/sets.html > >Regards, >Allan. =================================== Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.comArticle: 40469
The leakage current will vary dramatically (AKA exponentially) with temperature. The 300uA numbers in the datasheet are for room temp only. Also, all your inputs must be driven to one of the supply rails, anything between VDD and VSS on an input will leak juice and drain your battery. The outputs cannot be left driving anything except a FET gate. If you haven't been through this game before, it can really be an task trying to patch all the leaks. Did something similar for a USB device trying to make the 500uA standby requirement. Regards Peter Alfke <palfke@earthlink.net> wrote in message news:<3C86D98F.1305708A@earthlink.net>... > I can obviously not speak for Altera, but here are some general > observations: > > If the manufacturer made sure that all dc-consuming utilities are turned > off as soon as the normal Vcc disappears, and if the process is somewhat > old-fashioned ( >0.5 micron), then there is a chance. XC3000L used to > consume <50 microamps, which is an acceptable (barely!) value. > > If the manufacturer did not pay special attention, and does not indicate > so in the data sheet, your hopes are slim. > For all really up-to-date devices with geometries below 0.2 microns, (or > 200 nanometers as it is more fashionably called), there is no hope. The > inherent so-called leakage current is milliamps ( and more). > > But you can always try it out by measuring, both at room and at slightly > elevated temperature... > > > Peter Alfke, Xilinx Applications > ==================================== > Chris Cowdery wrote: > > > I am considering using a lithium battery on a board instead of a > > config device to enable my Altera FLEX10KA to retain its > > configuration. > > > > Has anyone any idea of the absolute min quiescent current I can expect > > a 10KA to draw? > > > > Thanks, > > > > Chris.Article: 40470
In that case use NRZ, look at what is done in USB 1.0. Its NRZ at 12Mb/s. The SEI (serial interface engine) is public domain. The input signal is sampled with the 4x clock in the traditional way. A DPLL resynchronizes on every data transition and is in turn used to pick the correct phase to sample data. You need bit stuffing or something like that at the transmitter to generate transitions to maintain synchronization of the receiver with your transmitter because during long periods of mark or space, the 2 clocks will drift. Regards "Roberto Capobianco" <capobianco@igi.pd.cnr.it> wrote in message news:<3c8780ec$1@news.mhogaming.com>... > Thank you Peter for reply, > yes i have a 100MHz free running receiver clock (4x oversampling). > Just few questions. In the case of NRZ transmission is correct to > synchronize the incoming signal with > my 100MHz clock (with a classic two stage flip-flops, no problem for me two > clock cycles delay) and after > to do sampling on synchronized signal or is better to do sampling directly > on incoming signal ? > In the case of Manchester transmission (50MHz transmission clock in this > case) receiver clock should be 200MHz (4x oversampling). > Maybe this frequency is too high for me. Can i do a manchester decoder with > different technique, maybe PLL with 50MHz > reference clock ? > > Thanks. > > > Roberto Capobianco > Consorzio RFX - CNR di Padova > C.so Stati Uniti, 4 > 35127 - Camin (PD) > email: capobianco@igi.pd.cnr.it > web: www.igi.pd.cnr.it > tel.: +39-049-8295048 > fax: +39-049-8700718 > > > > > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message > news:3C86944B.F4D25F0@xilinx.com... > > NRZ is fine if you have exactly the same clock at the transmitting and the > > receiving end. > > If there is any question about clock accuracy, then Manchester is much > better, > > since it is kind of self-clocking. But it has far more transitions ( max > two per > > bit, vs max 1 for NRZ). That limits the max bandwidt, but may not be a > problem > > with fibre. > > 8 or even 4 times oversampling with a free-running receiver clock is ok, > > provided you have solid signals, and almost no clock frequency > uncertainty. > > > > Peter Alfke, Xilinx Applications > > ============================== > > Roberto Capobianco wrote: > > > > > Hi all, > > > i want to send on fiber a digital pattern of approximately 50 bits with > Tbit > > > = 40ns (25MHz transmission clock). > > > First question : NRZ or Manchester code ? > > > Second question: UART and Manchester decoders in FPGA often use 16x > > > oversampling to sample at mid-bit of data cell. > > > This is impossible for me. > > > In the design at http://www.xilinx.com/xcell/xl17/xl17-30.pdf we have a > 8x > > > oversampling manchester decoder > > > but with my flex (Altera ACEX 1K) is very difficult to have a single > global > > > clock at 200MHz for all. > > > Exist different ways to realize a good sampling with a low frequency ? > > > > > > Thanks. > > > > > > -- > > > Roberto Capobianco > > > Consorzio RFX - CNR di Padova > > > C.so Stati Uniti, 4 > > > 35127 - Camin (PD) > > > email: capobianco@igi.pd.cnr.it > > > web: www.igi.pd.cnr.it > > > tel.: +39-049-8295048 > > > fax: +39-049-8700718 > >Article: 40471
I haven't seen the spec but I'd imagine that its more of a maximum current spec before your burn it up. Its fabed with the same process technology as all the junctions on the die, so maybe the max operating conditions for the part would be a hint of the diodes range? This is a good Peter question. Regards Cindy <cindicater@hotmail.com> wrote in message news:<ee7548a.-1@WebX.sUN8CHnE>... > Is there is absolute maximum voltage specified for the DXP and DXN pins? > > Thanks!Article: 40472
What about one of those Roboclock chips and the likes that you see from Cypress and others. I vaguely remember them being digitally programmable PLLs. Regards Martin Thompson <martin.j.thompson@trw.com> wrote in message news:<uelixtz18.fsf@trw.com>... > Austin Lesea <austin.lesea@xilinx.com> writes: > > > Martin, > > > > Nope. > > > > How about the 2V40? Pretty tiny, cs144 package (smallest)? > > > > I wonder... could I solder onto the balls for prototyping..... > > Anyone have any ballpark idea how much these devices cost? > > Cheers, > MartinArticle: 40473
Free (for download version) or not, anyone interested in making serious use of Altera or Xilinx toolsets (and the synth/sim products that go along with them) would be well advised to use Win2K rather than W9x or WME. What do I mean by the term "serious use" ? You need to get your job DONE, as in MAKE A LIVING. If X and A don't say as much explicitly, there are occasional clues (e.g. WinNT, W2K or higher RECOMMENDED). Just because you can get some of your work done on W9x doesn't mean it's a good idea. We could go on and on about the "my rights" vs. "corporate slime" vs. "lazy programmers" issues forever, but I don't think we could add any new insights to the discussion. Do you want to be "right", or do you want to design stuff? So.... That's life. Now move on and get work done. -- Bob Elkind "Kevin Brace" <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:a648lj$1fb$1@newsreader.mailgate.org... > Peter Ormsby wrote: > > > > > > Kevin, > > > > You have been exceedingly critical of Altera long before QII v2.0 WE was > > ever released. > ... snipped stuff > Yes, I use a Windows 98 PC which is known for its legendary instability, > but still XST doesn't crash like that. > You might say that Altera didn't write LS (Mentor Graphics/Exempler > Logic did), but if it is so buggy that it crashes when stop button is > pressed why is Altera distributing such software, even if it is free? > One of my major complaint of QII 1.1/2.0 (only tried Web Edition > though) is that for some reason, QII drains Windows 9x's system > resources much more heavily than ISE WebPACK. > Because Windows 98 is so bad, I always have to put Resource Meter on the > side of my screen, and whenever QII is running, I see it draining large > amounts of system resources, which comes back if I exit QII, but each > time this happens, I have to interrupt what I was doing, and I don't > like that. > Altera seemed to have made no improvements there compared to QII 1.1. > I read somewhere that Altera doesn't recommend using QII under Windows > 98, and instead recommend using Windows NT 4.0 or 2000, but I sort of > suspect that is because the system resource issue.Article: 40474
Jay, It is intended to be exactly equivalent to a 1N914 diode. Austin Jay wrote: > I haven't seen the spec but I'd imagine that its more of a maximum > current spec before your burn it up. Its fabed with the same process > technology as all the junctions on the die, so maybe the max operating > conditions for the part would be a hint of the diodes range? This is > a good Peter question. > > Regards > > Cindy <cindicater@hotmail.com> wrote in message news:<ee7548a.-1@WebX.sUN8CHnE>... > > Is there is absolute maximum voltage specified for the DXP and DXN pins? > > > > Thanks!
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