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
I have some Verilog code that generates an array of blockRAMs to any dimensions that I want. For example, if I set LENGTH=3 and HEIGHT=4 then 12 blockRAMs get synthesized. I have a separate script written in Ruby that creates the initial blockRAM contents according to the position of each blockRAM in the array. What I'd like to do is be able to pass in the blockRAM init parameters dynamically as each blockRAM is generated. I'm looking for suggestions on how to do this. Can XST execute and interact with scripts from the command line?Article: 114151
It sounds like you have a software solution that you want to implement in hardware. I don't think who should be too hung up on the iterative nature of your algorithm but instead you need to rewrite your algorithm targeting hardware or taking advantage of the VHDL. You should be looking for things that can be done in parallel. Pipelining can reduce the need for memory. An example from your description is as areas of interest are identified, instead of marking them, pass them onto the next stage in the solution. I evaluated a couple of different C-to-HDL compilers. Most times they require you to rewrite code to work within their environment. To some extent it is like learning a new or another language. Now don't get me wrong, there are still advantages to using these tools but I found the VHDL that they produce wasn't optimal but 'safe'. I instead decided to spend my time becoming a better VHDL programmer. My advice is start by implementing your solution as a state machine. In your algorithm, break up compound statements into simple steps. Each step becomes a state. I developed a technique for implementing for-next loops that I could easily manage. What I found was, while my solutions required a lot of cycles, I could achieve higher clock frequencies. After I was able to get a working solution that matched my software implementation I went back and identified things that I could implement as parallel units and pipeline. The other thing I wanted to do was reduce the number of multipliers I was using. So, I recoded them as shared hardware instead. The amount of combinational logic I was using went up but I was able to reduce the number of multipliers to 4 from 36.Article: 114152
Brad, what you describe is true in FWFT (first-word-fall-through) mode. In NORMAL mode, RE is required to even see the first word at the output. The difference between the two modes (available in all Virtex-4 and Virtex-5 chips) is only relevant for reading the very first word that had been written into an empty FIFO. Afterwards, RE gives you the next available word, as you descibe it, and this behavior is then independent of the mode setting. I envision the read operation in FWFT as "push out" and NORMAL as "pull out". The difference is subtle, and important only for operation around the EMPTY situation. Peter Alfke, Xilinx Applications On Jan 5, 10:08 am, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > That's not my recollection. It seems to me as soon as you do your > first write enable, data will be available at the output some > clock cycles later. It's better to think of the RD_EN as a GET_NEXT > signal, rather than a READ. > > Brad Smallridge > AiVision > > "John" <n...@null.com> wrote in messagenews:eea1578.-1@webx.sUN8CHnE... > > The read and write signals have to be set one clock cycle before the > > action right? If I do the following, will it read the first FIFO byte? > > > ... RD_EN <= '1'; TEST <= FIFO_OUT; ...Article: 114153
Symon wrote: > "PeteS" <PeterSmith1954@googlemail.com> wrote in message > news:1167756610.915575.324880@42g2000cwt.googlegroups.com... >> I'm facing that issue right now for a FT256 package, and I'll do what >> I've done with all the other RoHS BGA parts I've had done leadfree (and >> that's quite a few) - use non-SMD pads with the recommended sizes from >> the leaded versions. >> >> Cheers >> >> PeteS >> > Hi Pete, > I read somewhere* that engineers used solder mask defined (SMD) pads for > early BGAs because the parts were made of ceramic and could pull the pads > off the board during vibration testing. With a SMD pad I guess the pad area > can be larger to stop this. When lighter packages came along, the SMD pads > were no longer needed, but folks carried on with SMD pads maybe because** > "that's the way we've always done it". However, it turns out that SMD pads > have a proclivity for microvoids*** at the pad/solder boundary. > So, I wonder, now that Xilinx BGAs have metal heat spreaders built in, > whether their mass has increased enough to make the SMD pad necessary once > again. What do you think? > > Cheers, Syms. > > * http://www.smta.org/knowledge/proceedings_abstract.cfm?PROC_ID=252 > ** http://www.ojar.com/view_2857.htm > *** http://www.microvoids.org/ > > I've been bitten *very* hard from SMD pads on BGAs, especially fine pitch stuff. I've put down a lot of devices with heat spreaders on non-SMD and never had a failure due to reflow, but I've had a *lot* of failures (microvoids -> HiZ, and shorts pad to pad) using SMD whether they had heat spreaders or not. Unless there is a compelling reason for SMD pads (some specialised manufacturers specify it and I *always* ask for the reason) I won't use them. Cheers PeteSArticle: 114154
I've been looking all over for a board with a Xilinx V4 LX160 or 200 FPGA and 2 10/100 Ethernet PHYs. Closest I got was a board from Avnet that only had 1 PHY. Know where to find one? Please let me know. Many thanks.Article: 114155
Jonathan Bromley wrote:
> On 4 Jan 2007 07:14:21 -0800, "Tim Verstraete"
> <tim.verstraete@barco.com> wrote:
>
> [Also posted to comp.lang.vhdl]
>
>> ok, your right, now i know why it works on this code and not mine, in
>> the template i used the following libraries:
>>
>> LIBRARY ieee;
>> USE ieee.std_logic_1164.ALL;
>> use ieee.std_logic_arith.all;
>> use ieee.std_logic_signed.all;
>>
>> and in mine i used
>>
>> library IEEE;
>> use IEEE.STD_LOGIC_1164.ALL;
>> use IEEE.STD_LOGIC_ARITH.ALL;
>> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
> And that is PRECISELY why I keep banging on about why
> STD_LOGIC_(UN)SIGNED is such a very, very bad thing.
>
> If you had used only STD_LOGIC_ARITH or (better)
> NUMERIC_STD, then you would have been forced into
> declaring the objects as SIGNED or UNSIGNED, and you
> would know what you were doing. Having an arbitrary
> numeric representation imposed on std_logic_vector
> by a use clause is IMO certifiably insane.
>
> Thanks for providing more ammunition for my rant :-)
These newsgroups provide plenty
of this sort of ammunition.
The source, it seems to me,
is the training examples and
editor templates from brand X and brand S.
The result is that most designers of
VHDL synthesis code are convinced that
using signed and unsigned types is a waste of time,
and that only "purists" think otherwise.
This state of affairs is only a problem
for me when I use or supply entities to
other designers. My workaround in this case
is to declare [un]signed variables for use
in my entity and implicit type conversion
for port input and output assignments
from the omnipresent std_logic_vector type.
-- Mike Treseler
Article: 114156Davy, You really have not provided enough information to make any judgment at this point. What is the desired frequency of your design? What frequency does your static timing analysis say it will run at? What did you set your clock constraints at? With DC and ASIC libraries, it is very common to overconstrain the clock by between 10 to 20%. If you did not do this, I would do this first. If you are using DC for FPGAs, you are using the wrong tool, my first step in this case would be to use the free versions of Xilinx and Altera and see if that does not fix your issue. If you do use DC for FPGAs, expect it to be a wrestling match - there are lots of coding and tool tricks. Next I would look at the long timing paths. What caused them? Look at the logic created. Is it what you expected? If it is not what you expected, then you need to re-write your code so that it does create the hardware you want - this can be a trial and error process. Usually you start with a picture of what you want and make the code match it. If that does not work, further refine the picture until the code does give you what you want. Next I would look at potential false and multi-cycle paths as the others suggested. However, I do not like doing this unless I have to because if you are wrong, your final silicon will not work. Your last alternative is pipelining, architecture exploration, and changing the clock frequency. Good Luck, Jim > Hi all, > > I am new to Synopsys DC. And I have a basic problem. When I find timing > violation in DC report, what shall I do first? > > 1. Shall I change the script of DC? To let the tools do something like > retiming? > 2. Shall I change the RTL code? To pipeline the comb logic manually? > 3. Other choice, please recommend. > > What circumstance to do "1" or "2" or "1 and 2 at the same time"? > > Best regards, > Shenli >Article: 114157
Hi, I am wondering if I wrote the timing constraint properly. I have 2 clocks (clk, phy_rx_clk) coming in from the outside. clk is used to run part of my FF phy_rx_clk goes in a dcm and I use CLK0 and CLK180 output of the dcm. The data coming into the FPGA will have a minimum setup time 1.4 ns and minimum hold time 1.2 ns. CLK0 and CLK180 are used on DDR clock inputs. I need to make sure the setup and hold time will not be violated so i setup the constraint file as follows. I was wondering if somebody could check it out and let me know if I am doing anything wrong. NET "clk" TNM_NET = "clk_grp"; TIMESPEC "TS_clk" = PERIOD "clk_grp" 8 ns HIGH 50 %; NET "phy_rx_clk" TNM_NET = "phy_rx_clk_grp"; TIMESPEC "TS_phy_rx_clk" = PERIOD "phy_rx_clk_grp" 8 ns HIGH 50 %; NET "CLK0_rx" TNM = "CLK0_rx_grp"; NET "CLK180_rx" TNM = "CLK180_rx_grp"; TIMEGRP "CLK0_rx_grp_ddr" = RISING "CLK0_rx_grp"; # Check wrt rising edge TIMEGRP "CLK180_rx_grp_ddr" = RISING "CLK180_rx_grp"; # Check wrt rising edge OFFSET = IN 1.4 ns BEFORE "phy_rx_clk" TIMEGRP "CLK0_rx_grp_ddr"; #1.4ns setup OFFSET = IN 1.2 ns AFTER "phy_rx_clk" TIMEGRP "CLK0_rx_grp_ddr"; #1.2ns hold For some reason I get WARNING:ConstraintSystem:65 - Constraint <OFFSET = IN 1.2 ns AFTER COMP "phy_rx_clk" TIMEGRP CLK0_rx_grp_...> [.\ethernet.pcf(556)] overrides constraint <OFFSET = IN 1.4 ns BEFORE COMP "phy_rx_clk" TIMEGRP CLK0_rx_grp...> [.\ethernet.pcf(554)]. I cannot figure out why. Anybody can enlighten me. I am using Xilinx ISE 8.2Article: 114158
Has anyone here seen (or better yet, used) eASIC? http://www.easic.com It seems to be an FPGA programmed using a laser (so not really "F" PGA). Of course, this means it isn't re-writeable. Claims to be price competitive to FPGAs (even in small quantities). Opinions?Article: 114159
On Tue, 2 Jan 2007 10:14:21 -0000, "Symon" <symon_brewer@hotmail.com> wrote: ><smount> wrote in message news:4599cdbe$1_4@mk-nntp-2.news.uk.tiscali.com... >> Does anyone know what is needed to work with surface mount >> ic's, what sort of starting price tag are we talking about? >> (Assuming I have ready made boards, i.e. only the soldering >> phase is required) >> >Hi, >Try this Google search:- >solder group:comp.arch.fpga author:freidin > >Philip gives a list of links you'll find interesting. >HTH, Syms. http://www.fpga-faq.com/archives/96550.html#96560 I recently bought this: http://www.sra-solder.com/aoyue_2702.htm and this: http://store.amscope.com/sm-3tz.html and this: http://store.amscope.com/md600.html I plan to create training movies on how to do SMT board assembly, SMT rework, and SMT repair. Any interest? Philip Philip Freidin FliptronicsArticle: 114160
Hi, I am trying to make 7:1 LVDS Tx for a display solution (XGA and SXGA) and trying to use the approach as specified in xilinx app note XAPP704 (virtex-4 high speed single data rate LVDS transceiver). The reference design that xilinx provided is for 4:1 (4 parallel data goes to 1 channel of LVDS) and it works fine but when I try to change the parameters to operate as 7:1 the design doesn't work (the serial data output doesn't correspond to parallel data input). As the maximum bit per channel for a xilinx OSERDES is 6 I have to use two OSERDES in seires (as master and slave) to make a 7:1 channel. I would like to know if any worked on this aspect before and I do appreciate if any one can provide some helpful info to proceed. Regards raoArticle: 114161
David, Per their website, they have 5 members of their 90nm technology, with basic fabric clock speed of 350 MHz. They offer a version with embedded ARM processor, too. They do not have a 65nm product offering (yet). The Xilinx 65nm V5 line has a fabric which runs to 550 MHz (along with all the stuff that has to run with it). The V4 line has all 17 parts shipping. The V5 line has all 6 LX parts in ES now, and all 6 LXT ES is just starting. That is 12 family members in the logic specific family, alone. Then you add the SX, SXT, FX, FXT... They do not have the following hardened macros: MGTs DSP blocks TEMACs PCIe PPCs (plural, as in two IBM Power PC's in the larger parts) APU etc. I would think that they would have a huge line of hard blocks to spice up their offering, but then that requires a massive support burden (so they don't?). They do not have domain specific families, such as logic, digital signal processing, or high speed serial IO/embedded processors (basically the LX, SX and FX mix we offer). They do not offer a lower performance, cost reduced option line (Spartan), nor is there any offering to immediately reduce costs (like our EasyPath-tm). They (claim) offer "ASIC" like power (as in very low static power, but since I have to register to read their datasheet, I can't verify that). They do offer fast turnaround (once you know it works). They do have smaller die (fewer transistors, cost per die are low). I would be concerned about their SEU tolerance, as 90nm ASIC are at about 1000 FIT/Mb or M gates. That puts their largest device at 10 years between failures from SEU's (compared with >50 times that number for the comparable V5 part, or greater than 500 years MTBFF). So, nice line, looks useful. How does it compare/compete with a re-programmable "latest and greatest" FPGA Family? That is up to you, the engineers who have the applications. Austin David R Brooks wrote: > Has anyone here seen (or better yet, used) eASIC? http://www.easic.com > > It seems to be an FPGA programmed using a laser (so not really "F" PGA). > Of course, this means it isn't re-writeable. > Claims to be price competitive to FPGAs (even in small quantities). > > Opinions?Article: 114162
Austin Lesea wrote: > David, > > Per their website, they have 5 members of their 90nm technology, with > basic fabric clock speed of 350 MHz. They offer a version with embedded > ARM processor, too. > > They do not have a 65nm product offering (yet). The Xilinx 65nm V5 line > has a fabric which runs to 550 MHz (along with all the stuff that has to > run with it). > > The V4 line has all 17 parts shipping. The V5 line has all 6 LX parts > in ES now, and all 6 LXT ES is just starting. That is 12 family members > in the logic specific family, alone. Then you add the SX, SXT, FX, FXT... > > They do not have the following hardened macros: > MGTs > DSP blocks > TEMACs > PCIe > PPCs (plural, as in two IBM Power PC's in the larger parts) > APU > etc. > I would think that they would have a huge line of hard blocks to spice > up their offering, but then that requires a massive support burden (so > they don't?). > > They do not have domain specific families, such as logic, digital signal > processing, or high speed serial IO/embedded processors (basically the > LX, SX and FX mix we offer). > > They do not offer a lower performance, cost reduced option line > (Spartan), nor is there any offering to immediately reduce costs (like > our EasyPath-tm). > > They (claim) offer "ASIC" like power (as in very low static power, but > since I have to register to read their datasheet, I can't verify that). > They do offer fast turnaround (once you know it works). They do have > smaller die (fewer transistors, cost per die are low). > > I would be concerned about their SEU tolerance, as 90nm ASIC are at > about 1000 FIT/Mb or M gates. That puts their largest device at 10 > years between failures from SEU's (compared with >50 times that number > for the comparable V5 part, or greater than 500 years MTBFF). > > So, nice line, looks useful. How does it compare/compete with a > re-programmable "latest and greatest" FPGA Family? That is up to you, > the engineers who have the applications. > > Austin > > > > David R Brooks wrote: >> Has anyone here seen (or better yet, used) eASIC? http://www.easic.com >> >> It seems to be an FPGA programmed using a laser (so not really "F" PGA). >> Of course, this means it isn't re-writeable. >> Claims to be price competitive to FPGAs (even in small quantities). >> >> Opinions? Without having seen the line information, but having seen such types of announcement in the past I would ask: Is there true characterisation data? a. IO b. IOBuf delays c. Pin details d. (Most important) Icc vs. specific implementations. I have yet to see one of these parts compete properly on power and cost against the two competitors -> FPGA for effective cost and flexibility -> true ASIC *or* controller for low power (no offense, but FPGAs just can't compete in the really low power domain). I'll have a look tomorrow Cheers PeteSArticle: 114163
I'm running 8.2.03i, and expected to find the 2-D DCT core when I fired up the core generator. It either wasn't there, or I'm going blind. Where might I find it? ThanksArticle: 114164
> As the maximum bit per channel for a xilinx OSERDES is 6
> I have to use two OSERDES in
> seires (as master and slave) to make a 7:1 channel.
I have been able to get the master/slave OSERDES going at 7:1 rates.
It's required for Camera Link interfaces, however, I used the single
clock edge rate. No amount of kludging allowed the double edge rate.
Perhaps the VHDL code below will give you some clues:
Brad Smallridge
AiVision
signal shift1 : std_logic;
signal shift2 : std_logic;
begin
OSERDES_master : OSERDES
generic map (
DATA_RATE_OQ => "SDR", -- Specify data rate to "DDR" or "SDR"
DATA_RATE_TQ => "BUF", -- Specify data rate to "DDR", "SDR", or
"BUF"
DATA_WIDTH => 7, -- DDR: 4,6,8,10 SDR BUF: 2,3,4,5,6,7, or 8
INIT_OQ => '0', -- INIT for Q1 register - '1' or '0'
INIT_TQ => '0', -- INIT for Q2 register - '1' or '0'
SERDES_MODE => "MASTER", -- Set SERDES mode to "MASTER" or "SLAVE"
SRVAL_OQ => '0', -- Define Q1 output value upon SR assertion -
'1' or '0'
SRVAL_TQ => '0', -- Define Q1 output value upon SR assertion -
'1' or '0'
TRISTATE_WIDTH => 1) -- Specify parallel to serial converter width
-- When DATA_RATE_TQ = DDR: 2 or 4
-- When DATA_RATE_TQ = SDR or BUF: 1 "
port map (
OQ => q, -- 1-bit output
SHIFTOUT1 => open, -- 1-bit output
SHIFTOUT2 => open, -- 1-bit output
TQ => open, -- 1-bit output
CLK => clk, -- 1-bit input
CLKDIV => clkdiv, -- 1-bit input
D1 => data(0), -- 1-bit input
D2 => data(1), -- 1-bit input
D3 => data(2), -- 1-bit input
D4 => data(3), -- 1-bit input
D5 => data(4), -- 1-bit input
D6 => data(5), -- 1-bit input
OCE => '1', -- 1-bit input
REV => '0', -- 1-bit input
SHIFTIN1 => shift1, -- 1-bit input
SHIFTIN2 => shift2, -- 1-bit input
SR => '0', -- 1-bit input
T1 => '0', -- 1-bit input
T2 => '0', -- 1-bit input
T3 => '0', -- 1-bit input
T4 => '0', -- 1-bit input
TCE => '0' ); -- 1-bit input
OSERDES_slave : OSERDES
generic map (
DATA_RATE_OQ => "SDR", -- Specify data rate to "DDR" or "SDR"
DATA_RATE_TQ => "BUF", -- Specify data rate to "DDR", "SDR", or
"BUF"
DATA_WIDTH => 7, -- DDR: 4,6,8,10 SDR BUF: 2,3,4,5,6,7, or 8
INIT_OQ => '0', -- INIT for Q1 register - '1' or '0'
INIT_TQ => '0', -- INIT for Q2 register - '1' or '0'
SERDES_MODE => "SLAVE", -- Set SERDES mode to "MASTER" or "SLAVE"
SRVAL_OQ => '0', -- Define Q1 output value upon SR assertion -
'1' or '0'
SRVAL_TQ => '0', -- Define Q1 output value upon SR assertion -
'1' or '0'
TRISTATE_WIDTH => 1) -- Specify parallel to serial converter width
-- When DATA_RATE_TQ = DDR: 2 or 4
-- When DATA_RATE_TQ = SDR or BUF: 1 "
port map (
OQ => open, -- 1-bit output
SHIFTOUT1 => shift1, -- 1-bit output
SHIFTOUT2 => shift2, -- 1-bit output
TQ => open, -- 1-bit output
CLK => clk, -- 1-bit input
CLKDIV => clkdiv, -- 1-bit input
D1 => '0', -- 1-bit input
D2 => '0', -- 1-bit input
D3 => data(6), -- 1-bit input
D4 => '1', -- 1-bit input
D5 => '1', -- 1-bit input
D6 => '1', -- 1-bit input
OCE => '1', -- 1-bit input
REV => '0', -- 1-bit input
SHIFTIN1 => '0', -- 1-bit input
SHIFTIN2 => '0', -- 1-bit input
SR => '0', -- 1-bit input
T1 => '0', -- 1-bit input
T2 => '0', -- 1-bit input
T3 => '0', -- 1-bit input
T4 => '0', -- 1-bit input
TCE => '0' ); -- 1-bit input
Article: 114165Hello, I'm looking to implement an Ethernet Controller to support 1000Base-T on a Stratix II GX and would like to know if anyone could suggest an IP Core? I've been looking over the Atlera IP web site and have found some IP's, but I wanted to see what other people were using. thanks, joeArticle: 114166
Philip Freidin wrote: > I recently bought this: http://www.sra-solder.com/aoyue_2702.htm > > and this: http://store.amscope.com/sm-3tz.html > > and this: http://store.amscope.com/md600.html > > I plan to create training movies on how to do SMT board assembly, > SMT rework, and SMT repair. Any interest? > > Philip Now all you need is a Gerber-driven solder paste dot printer! They exist, and news of an affordable unit for prototyping would be interesting. TimArticle: 114167
Hello. I have a peripheral with an AMBA APB interface. The issue that I am facing is that of clock domain crossing. The processing logic in the peripheral is required to operate at a relatively slow clock frequency, but the clock frequency of the APB interface can be 4 to 5 times that of the slow clock domain. I have been considering the two clock domains as asynchronous with respect to each other, even though the faster clock is generated from the slow clock by means of a PLL; therefore, the phase relationship between the two clock should be constant. My problems lies in the fact that APB has no signal to hold the bus in the case where the data from a write cycle to the slow clock domain has not yet been registered by the slow clock when a second write cycle starts to happen. I am considering to options: 1) Have the Configuration Registers clocked with the fast clock signal and only have event signals generated by a write or a read cross the clock domain boundary. 2) Buffer data with a FIFO and synchronize the control signals to the slow clock domain. Any suggestions would be appreciated. Thank you in advance. Best Regards, Marco.Article: 114168
Hi Fred, This was actually a bug in ISE Simulator in the 8.xi versions. We have addressed this in ISE 9.1i. After doing some research we found out that a majority of users like to see the values in HEX rather than decimal. This is why in ISE 9.1i, ISE Simulator will always default to HEX in the waveforms. Also another feature we have added is to save the settings such as the radix and the order of the signals once you have changed it. This is now saved on a per project basis, so the next time you reopen the simulation, if you had right clicked and selected that you wanted the bus to be in ASCII for example, then it will maintain your preference. Hope that this helps Thanks Duth Fred wrote: > The default radix on waveforms is decimal and although I can right click the > waveforms and change the radix to hex, it reverts back to decimal if I > resimulate the design. > > Is there any way in the test bench VHDL file, or anywhere else, I can force > the radix to remain to be hexadecimal?Article: 114169
Hi
Thank you for your info.
My design is in verilog and almost simular as you have shown
( except for the slave OSERDES my connections are
> D1 => open, -- 1-bit input
> D2 => open, -- 1-bit input
> D3 => data(6), -- 1-bit input
> D4 => open, -- 1-bit input
> D5 => open, -- 1-bit input
> D6 => open, -- 1-bit input ).
I tried your approach of 0 for D1 and D2, 1 for D4, D5 and D6 for
Slave.
But I couldn't verify the serial Data of the channel w.r.to the
parallel data input to the
channel.
Suppose the parallel data is [ABDCEFG] then in next clkdiv cycle the
channel data
output should be A-B-C-D-E-F-G per clk. I could n't verify the
process.
// Master
OSERDES TX_DAT_OUT_00 (.OQ(PREDATOUT[0]), .SHIFTOUT1(),
.SHIFTOUT2(), .TQ(), .CLK(TXCLK), .CLKDIV(TXCLKDIV), .D1(DI[0]),
.D2(DI[1]), .D3(DI[2]), .D4(DI[3]), .D5(DI[4]), .D6(DI[5]),
.OCE(OCE), .REV(1'b0), .SHIFTIN1(S2M1[0]), .SHIFTIN2(S2M2[0]),
.SR(ORST), .T1(), .T2(), .T3(), .T4(), .TCE());
// Slave
OSERDES TX_DAT_OUT_00S (.OQ(), .SHIFTOUT1(S2M1[0]),
.SHIFTOUT2(S2M2[0]), .TQ(), .CLK(TXCLK), .CLKDIV(TXCLKDIV), .D1(1'b0),
.D2(1'b0), .D3(DI[6]), .D4(1'b1), .D5(1'b1), .D6(1'b1),
.OCE(OCE), .REV(1'b0), .SHIFTIN1(), .SHIFTIN2(),
.SR(ORST), .T1(), .T2(), .T3(), .T4(), .TCE());
Regards
rao
Brad Smallridge wrote:
> > As the maximum bit per channel for a xilinx OSERDES is 6
> > I have to use two OSERDES in
> > seires (as master and slave) to make a 7:1 channel.
>
> I have been able to get the master/slave OSERDES going at 7:1 rates.
> It's required for Camera Link interfaces, however, I used the single
> clock edge rate. No amount of kludging allowed the double edge rate.
>
> Perhaps the VHDL code below will give you some clues:
>
> Brad Smallridge
> AiVision
>
>
> signal shift1 : std_logic;
> signal shift2 : std_logic;
>
> begin
>
> OSERDES_master : OSERDES
> generic map (
> DATA_RATE_OQ => "SDR", -- Specify data rate to "DDR" or "SDR"
> DATA_RATE_TQ => "BUF", -- Specify data rate to "DDR", "SDR", or
> "BUF"
> DATA_WIDTH => 7, -- DDR: 4,6,8,10 SDR BUF: 2,3,4,5,6,7, or 8
> INIT_OQ => '0', -- INIT for Q1 register - '1' or '0'
> INIT_TQ => '0', -- INIT for Q2 register - '1' or '0'
> SERDES_MODE => "MASTER", -- Set SERDES mode to "MASTER" or "SLAVE"
> SRVAL_OQ => '0', -- Define Q1 output value upon SR assertion -
> '1' or '0'
> SRVAL_TQ => '0', -- Define Q1 output value upon SR assertion -
> '1' or '0'
> TRISTATE_WIDTH => 1) -- Specify parallel to serial converter width
> -- When DATA_RATE_TQ = DDR: 2 or 4
> -- When DATA_RATE_TQ = SDR or BUF: 1 "
> port map (
> OQ => q, -- 1-bit output
> SHIFTOUT1 => open, -- 1-bit output
> SHIFTOUT2 => open, -- 1-bit output
> TQ => open, -- 1-bit output
> CLK => clk, -- 1-bit input
> CLKDIV => clkdiv, -- 1-bit input
> D1 => data(0), -- 1-bit input
> D2 => data(1), -- 1-bit input
> D3 => data(2), -- 1-bit input
> D4 => data(3), -- 1-bit input
> D5 => data(4), -- 1-bit input
> D6 => data(5), -- 1-bit input
> OCE => '1', -- 1-bit input
> REV => '0', -- 1-bit input
> SHIFTIN1 => shift1, -- 1-bit input
> SHIFTIN2 => shift2, -- 1-bit input
> SR => '0', -- 1-bit input
> T1 => '0', -- 1-bit input
> T2 => '0', -- 1-bit input
> T3 => '0', -- 1-bit input
> T4 => '0', -- 1-bit input
> TCE => '0' ); -- 1-bit input
>
> OSERDES_slave : OSERDES
> generic map (
> DATA_RATE_OQ => "SDR", -- Specify data rate to "DDR" or "SDR"
> DATA_RATE_TQ => "BUF", -- Specify data rate to "DDR", "SDR", or
> "BUF"
> DATA_WIDTH => 7, -- DDR: 4,6,8,10 SDR BUF: 2,3,4,5,6,7, or 8
> INIT_OQ => '0', -- INIT for Q1 register - '1' or '0'
> INIT_TQ => '0', -- INIT for Q2 register - '1' or '0'
> SERDES_MODE => "SLAVE", -- Set SERDES mode to "MASTER" or "SLAVE"
> SRVAL_OQ => '0', -- Define Q1 output value upon SR assertion -
> '1' or '0'
> SRVAL_TQ => '0', -- Define Q1 output value upon SR assertion -
> '1' or '0'
> TRISTATE_WIDTH => 1) -- Specify parallel to serial converter width
> -- When DATA_RATE_TQ = DDR: 2 or 4
> -- When DATA_RATE_TQ = SDR or BUF: 1 "
> port map (
> OQ => open, -- 1-bit output
> SHIFTOUT1 => shift1, -- 1-bit output
> SHIFTOUT2 => shift2, -- 1-bit output
> TQ => open, -- 1-bit output
> CLK => clk, -- 1-bit input
> CLKDIV => clkdiv, -- 1-bit input
> D1 => '0', -- 1-bit input
> D2 => '0', -- 1-bit input
> D3 => data(6), -- 1-bit input
> D4 => '1', -- 1-bit input
> D5 => '1', -- 1-bit input
> D6 => '1', -- 1-bit input
> OCE => '1', -- 1-bit input
> REV => '0', -- 1-bit input
> SHIFTIN1 => '0', -- 1-bit input
> SHIFTIN2 => '0', -- 1-bit input
> SR => '0', -- 1-bit input
> T1 => '0', -- 1-bit input
> T2 => '0', -- 1-bit input
> T3 => '0', -- 1-bit input
> T4 => '0', -- 1-bit input
> TCE => '0' ); -- 1-bit input
Article: 114170iam using mentor graphics modelsim6.2d for running verilog codes,can anyone tell me how to use code coverage in batchArticle: 114171
"Peter Alfke" <peter@xilinx.com> wrote: >On Jan 5, 9:19 am, n...@puntnl.niks (Nico Coesel) wrote: >> "Lars" <lar...@gmail.com> wrote: >> >I've been looking all over but have been unable to find any numbers for >> >minimum clock-to-output propagation delay for Spartan3E. Anyone have a >> >clue as to what can be expected. The design is very straight forward: A >> >clock inut to a GCLK pin, a BUFG clock driver clocking an IO-block data >> >and output enable flip-flop. Maximum clock-to-output delay is reported >> >at some 6.8 ns. This matches fine the data in the Spartan3E data sheet >> >tables 85, 90 and 93 (5.51 ns + 0.43 ns + 0.70 ns for LVTTL clock input >> >and LVTTL 12 mA SLOW output). >> >> >But how can I find the minimum delay to satisfy the external component >> >hold time requirement of 1.5 ns? My reasoning that the fetch loop >> >clock-pad -> clock driver -> output ff -> output pad "ought" to be more >> >than 1.5 ns under all conditions, but it would shure feel better if I >> >could have it in writing!I have been looking for this also. Best thing to do is use the timing >> analyzer on an existing design. The minimum clock to output delay is >> used to calculate (IIRC) the hold timing. >> >The accepted definition is: 25% of the max value as it is specified for >the fastest speed grade. >(If the max delay for the fastest speed grad is 4 ns, then the min >value of that parameter for all speed grades is "no shorter than 1.0 >ns") >Assuming min to be "75% of max" is utter nonsense. >Why the wide range? >It covers temperature changes, Vcc changes, and processing variations, >and also testing guardbands. All of this in the worst-case direction. >Also; While max delays are tested, min delays are usually not testable, >and must be "guaranteed by design, or by characterization". >Luckily, a synchronous design is not concerned about min delays inside >the chip. >Memory interfaces often are sensitive, and ask for careful and creative > design methodologies. ...and for more precise numbers on internal and external timing. Which brings me to the question: how does the Xilinx timing analyzer determine the minimum delay? Does it use 25% of fastest max. value or does it use worst case delays obtained by measurements and simulation? -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 114172
On Fri, 05 Jan 2007 12:22:29 -0800, Mike Treseler <mike_treseler@comcast.net> wrote: >Jonathan Bromley wrote: >> On 4 Jan 2007 07:14:21 -0800, "Tim Verstraete" >> <tim.verstraete@barco.com> wrote: >> >> [Also posted to comp.lang.vhdl] >> >>> ok, your right, now i know why it works on this code and not mine, in >>> the template i used the following libraries: >>> >>> LIBRARY ieee; >>> USE ieee.std_logic_1164.ALL; >>> use ieee.std_logic_arith.all; >>> use ieee.std_logic_signed.all; >> Thanks for providing more ammunition for my rant :-) > >These newsgroups provide plenty >of this sort of ammunition. >The source, it seems to me, >is the training examples and >editor templates from brand X and brand S. Indeed. Furthermore, at least half the time, having included the std_logic_arith type libraries, the code doesn't ever use them! It is normal practice for me to comment out these "use" clauses; normally the code just compiles without them, and I have one less thing to worry about. (In the rare examples that actually use them, it's not usually difficult to make them numeric_std clean, though I don't always bother) - BrianArticle: 114173
marco wrote: > Hello. > > I have a peripheral with an AMBA APB interface. > The issue that I am facing is that of clock domain crossing. > The processing logic in the peripheral is required to operate at a > relatively slow clock frequency, but the clock frequency of the APB > interface can be 4 to 5 times that of the slow clock domain. > I have been considering the two clock domains as asynchronous with > respect to each other, even though the faster clock is generated from > the slow clock by means of a PLL; therefore, the phase relationship > between the two clock should be constant. > > My problems lies in the fact that APB has no signal to hold the bus in > the case where the data from a write cycle to the slow clock domain has > not yet been registered by the slow clock when a second write cycle > starts to happen. AMBA APB version 3 has such a signal I believe, pready. Cheers, JonArticle: 114174
"PeteS" <peter.smith8380@ntlworld.com> wrote in message news:Pyxnh.53333$UC.34379@newsfe5-win.ntli.net... > > I've been bitten *very* hard from SMD pads on BGAs, especially fine pitch > stuff. I've put down a lot of devices with heat spreaders on non-SMD and > never had a failure due to reflow, but I've had a *lot* of failures > (microvoids -> HiZ, and shorts pad to pad) using SMD whether they had heat > spreaders or not. > > Unless there is a compelling reason for SMD pads (some specialised > manufacturers specify it and I *always* ask for the reason) I won't use > them. > > Cheers > > PeteS > Hi Pete, Thanks for your comments. It more or less reflects my experiences, although I've not vibration tested an FPGA with heat-spreader design. On a related subject, what do you think about via-in-pad. I've had great success with this, but recently people seem to be shying away from it. http://www.pcblibraries.com/resources/GEN-docs.asp Near the bottom, Solving the Metric Pitch BGA & Micro BGA Dilemma On page 30, the guy says that the voids are no problem, which backs up my experience. I wondered if you have a view on this? Thanks, Syms.
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