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
wxy0624@gmail.com wrote: > That is exactly what I am doing now, and the FPGA is working properly > under lab condition. > It just a warning during simulation. > I just worry about when the environment, for example, the voltage > changes, the temperature changes, > or something like that. Usually, the timing analysis that is done by the tools uses a worst case scenario, like 85 °C temperature and a very low VCCINT. When you look at the logfile "par" produces (it's a text file with the ending .par in your project directory), there are lines like this at the beginning: "Initializing temperature to 85.000 Celsius. (default - Range: -40.000 to 100.000 Celsius) Initializing voltage to 1.140 Volts. (default - Range: 1.140 to 1.260 Volts)" You can even put the setting in you UCF: TEMPERATURE = 75 C; sets the temperature to 75 °C (pure magic!). I assume there's a similar setting for the core voltage. So unless your real-life environment isn't worse than that, you should be safe. HTH, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 127326
BobW wrote: > > Using the CLK0 and CLK180 DCM outputs into two BUFGs produces less duty > cycle distortion than using one clock at the IOB plus the IOB's locally > inverted clock, when doing DDR stuff. This makes sense because the locally > inverted clock will always have some delay with respect to its source clock. > The Xilinx documentation for high speed RAM interfaces should confirm this. > > I believe that Virtex5 is the first family to use differential clocks > internally, and this will further reduce duty cycle distortion when using > DDR techniques. > > Bob What about clock skew due to different loading of the two clocks? If there's 1.482 ns on one and 1.876 ns on the other, doesn't the 396 ps swamp out any duty cycle distortion? I'm hoping to find something more certain than "gut feel" for this issue. If anyone has produced results saying one way *is* better than the other, I'd love to know. If the clock routing produced the same delays, I'd agree that duty cycle distortion - different propagation delays for rising versus falling edges - would be a reason to go with clk180. Since the clock routing doesn't produce the same delays (as far as I know there's no way to get them to match) I'm still not sure what the best method is. - John_HArticle: 127327
Larry, The FPGA is not a battery. If there is that high a voltage on unconnected banks, well, they are obviously connected to something, aren't they? It could be that you have a 5V CMOS driver driving an input in that (those) bank(s), which causes the upper protection diode(s) to be forward biased. The voltages you have reported are greater than the abs max in the data sheet, so you risk blowing out the gates/junctions on the IO transistors in those banks -- DON'T DO THAT! AustinArticle: 127328
On Dec 18, 8:50 am, "RCIngham" <robert.ing...@gmail.com> wrote: > <snip /> > > > > >My problem was solved by using the package > >IEEE.std_logic_unsigned.ALL; and I used the function conv_integer > >which directly converts the std_logic_vector to integer. In this case > >i do not have to convert the vector to unsigned. > > >Thank you all for your help > > >Anuja > > If you ever go on a VHDL course, I am sure that you will be told that use > of the 'std_logic_arith', 'std_logic_signed', 'std_logic_unsigned' > packages is DEPRECATED, and that you should only use the IEEE Standard > 1076.3-1997 'numeric_std' (or 'numeric_bit' if not using 9-level logic) > package. I strongly advise you to get into this good habit now. Thank you very much for your adviseArticle: 127329
hmm, Played around with it a bit more...Removed the RX and enabled the loop back mode in a single MGT. The parallel mode gives the correct output while the serial mode has misalignment issue. Seems like it's nothing to do with clock correction i guess then... Thanks, ShakithArticle: 127330
Shakith, Generally speaking, if you turn off the encoding (8b10b or 64/66b), then you are responsible for aligning bytes, and frames (as the MGT now just sends bits, and gets bits, and has no knowledge of what to do with them). A major advantage of the encoding is it defines the beginning and end of bytes (allows for byte synchronization), and it also enforces a 1's density such that whatever data you decide to send is unaffected by long strings of 0's or 1's (with no encoding, serial channels will eventually lose sync if there are no transitions from 1 to 0 or - to 1 -- this is known as the "run length" and is something else you have to worry about if you turn off the encoding). My advice: leave 8b10b on, and do it the easy way. AustinArticle: 127331
Hi Folks, I am totally new to FPGA design, so excuse me if this doesn't make sense. Is it possible to configure the 18K Bram in Virtex II in a different way. For example as four different 512 deep blocks of 8- bits. What I want is FIFOs that are 512 deep and 8-bits wide, for my convolution core. I read through the Xilinx application note xapp258 where FIFOs for 16k, 8k, 4k, 2k and 511 are mentioned and from that it is not clear if we can build FIFOs of different sizes. And also are there any resources where i can get information about building FIFOs with BRAMs or distributed RAMS. Thanks and regards RamcArticle: 127332
On Dec 18, 8:41 am, RK <sun.ra...@gmail.com> wrote: > Hi Folks, > > I am totally new to FPGA design, so excuse me if this doesn't make > sense. Is it possible to configure the 18K Bram in Virtex II in a > different way. For example as four different 512 deep blocks of 8- > bits. What I want is FIFOs that are 512 deep and 8-bits wide, for my > convolution core. > > I read through the Xilinx application note xapp258 where FIFOs for > 16k, 8k, 4k, 2k and 511 are mentioned and from that it is not clear if > we can build FIFOs of different sizes. > > And also are there any resources where i can get information about > building FIFOs with BRAMs or distributed RAMS. > > Thanks and regards > Ramc http://www.google.com/search?hl=en&q=site%3Axilinx.com+fifos First hit is an spp note that can take you through much of what you need to know. The BRAM memories are dual-port memories meaning you could change 1 18kbit dual-port memory into two independent 9kbit single-port memories but the only way to decompose into four independent 4k memories is to time-multiplex your access to the memory array. There's no way to turn one memory into 4 memories since that would require a four-port configuration; since FIFOs normally use both ports of a memory, an 8-port memory would even be needed. Yikes! Typically FIFOs are built as one FIFO per BRAM. - John_HArticle: 127333
RK wrote: > I am totally new to FPGA design, so excuse me if this doesn't make > sense. Is it possible to configure the 18K Bram in Virtex II in a > different way. For example as four different 512 deep blocks of 8- > bits. No, the BRAMs only have two ports, so you can use them as two independent 1K*8 blocks. Or you can add logic to time-multiplex them, to get more ports. You could effectively get four 512*8 blocks by using both ports and 2:1 time multiplexing. EricArticle: 127334
Amontec, Larry wrote: > Hi All, > > We are on a new board with on-board XC3S250E-VQ100. > > All VCCint are 1.2V > All VCCaux are 2.5V > Bank0 VCCio are 3.3V > Bank2 VCCio are 3.3V > > Bank1 VCCio are un-driven (not powered) > Bank3 VCCio are un-driven (not powered) > Bank1 VCCio and Bank3 VCCio are connected together > > We can see a strange issue on VCCio of bank1 and Bank3 if they stay > un-driven (not powered). We can see a voltage of 4.64V on Bank1 VCCio > and Bank3 VCCio. > > Now if we charge a 200ohm resistor on Bank1 VCCio we can see a voltage > of 4.05V on Bank1 VCCio and Bank3 VCCio. > > Are there something wrong with our Spartan3E! > Why this 4.64V ? > > Please help to understand. I don't think the chip cannot manufacture voltages, so you need some simple tests * Check the voltmeter is correct * Find any higher voltages on the board - it is really is correct it must be coming from somewhere else. That's also quite a low impedance, you have pulled 24mA from the pin, and only dropped 600mV -jgArticle: 127335
Has anyone worked out a hack to get the USB-Blaster to work with Red Hat 5? I need to put DE1 project boards in a lab with linux boxes that have already been upgraded to RHEL 5. If anyone has figured it out, I'd appreciate hearing about it; otherwise, I'll have to dig into the USB driver stuff myself.Article: 127336
I am doing some initial research regarding PCB design process with a Spartan3E (FT256) .. Have i understood it correctly that avnet are the only distributor of xilinx FPGA=B4s ? .. in that case, i can order a Spartan3E witch is not lead free .. and here comes the problem -> we have vapor phase equipment to solder the BGA on the PCB. This vapor phase machine uses liquid which reach 240degrees (Pb-free soldering), will this damage the non-Pb-free FPGA? If it does, i have to convince some ppl to buy some other liquid with lower vapor temperature :/ I have read the Device Package Userguide (ug112), regarding the Reflow soldering process .. it dosent address the vapor phase process but i guess its the same as for a normal oven process? .. is it critical to obey the ramp temperature requirements? Regards KimArticle: 127337
Hi all, I'm having trouble trying to figure out why this VHDL synthesizes to something which generates glitches when post-route simulated in Modelsim. Regardless of what I do, I always get tons of warnings from VitalGlitch in Modelsim about glitches on slices involving "count". I am using Precision to synthesize. These tools are all part of Lattice ispLever v7.0. The clock is 1MHz. This is supposed to be a simple divide by 100 counter. I don't actually see any glitches as written (although they are reported by modelsim). However, if I remove the range restriction on count, I do see some glitches (this is all in sim...I have not checked for glitches in the actual HW). Please help! Thanks, Sean Here's the code: library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all; entity Tester is PORT ( CLK: IN std_logic; RESET: IN std_logic; CS: IN std_logic; OUTP: OUT std_logic; QA0_d: OUT std_logic; QA1_d: OUT std_logic); end; architecture RTL of Tester is COMPONENT clock IS --Divides 1MHz clock down to 10KHz PORT ( --Inputs CLK1M: IN std_logic; --1MHz clock RESET: IN std_logic; --Active Low --Outputs CLK10K: OUT std_logic); --10KHz clock END COMPONENT; begin div: clock PORT MAP ( CLK1M => CLK, RESET => RESET, CLK10K => OUTP); QA0_d <= '0'; QA1_d <= '0'; end RTL; Now the code for the module clock: LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.std_logic_unsigned.ALL; USE ieee.std_logic_arith.ALL; ENTITY clock IS PORT ( --Inputs CLK1M: IN std_logic; --1MHz clock RESET: IN std_logic; --Active Low --Outputs CLK10K: OUT std_logic); --10KHz clock END clock; ARCHITECTURE Behavioral OF clock IS BEGIN PROCESS(CLK1M, RESET) variable count: integer range 0 to 255; BEGIN IF RESET='0' THEN count := 0; CLK10K <= '0'; ELSIF rising_edge(CLK1M) THEN count := (count+1); IF count = 51 then clk10k <= '1'; elsif count = 100 then count := 0; clk10k <='0'; else null; end if; END IF; END PROCESS; END Behavioral;Article: 127338
On 2007-12-17, Robert Lacoste <> wrote: > > We are going to start a project in which we will need to use the hardware > MAC Ethernet module in a Virtex 5 for high speed transferrs (around 400KB/s) > through 1000BT. I'm looking for experience feedbacks : Anyone who has used > tihs module without a third-party TCP/IP stack (as we have in mind to We generated data by writing directly to a V4 hard_temac. We didn't configure it manually, though, there was other passthrough traffic from a plb_temac. The Linux driver configured the MAC (but there aren't that many host bus registers to set if you want to use only hard_temac). Remember you need a valid header, and an OS network stack is doing a lot behind the scenes to handle routing, arping, etc. If this is going off- board, you will need something to configure your PHY, too. It's actually easy to inject data into a hard_temac that's also being driven by a plb_temac because the interface lets the hard_temac (or your wedge) flow control the upstream. So you can block the plb_temac (as if you were a slow interface, or experiencing collisions) while you drive the hard_temac with your data. > Difficulties ? Quality of the documentation ? Virtex 4 > vs 5 ? Reference designs or good sources of information ? There are appnotes covering all of it. If you avoid 10/100 (and go 1000 only) things are simpler (MII vs GMII reverses some of the clock flow). -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 127339
On Dec 18, 10:11 am, John_H <newsgr...@johnhandwork.com> wrote: > BobW wrote: > > > Using the CLK0 and CLK180 DCM outputs into two BUFGs produces less duty > > cycle distortion than using one clock at the IOB plus the IOB's locally > > inverted clock, when doing DDR stuff. This makes sense because the locally > > inverted clock will always have some delay with respect to its source clock. > > The Xilinx documentation for high speed RAM interfaces should confirm this. > > > I believe that Virtex5 is the first family to use differential clocks > > internally, and this will further reduce duty cycle distortion when using > > DDR techniques. > > > Bob > > What about clock skew due to different loading of the two clocks? If > there's 1.482 ns on one and 1.876 ns on the other, doesn't the 396 ps > swamp out any duty cycle distortion? > > I'm hoping to find something more certain than "gut feel" for this > issue. If anyone has produced results saying one way *is* better than > the other, I'd love to know. > > If the clock routing produced the same delays, I'd agree that duty cycle > distortion - different propagation delays for rising versus falling > edges - would be a reason to go with clk180. Since the clock routing > doesn't produce the same delays (as far as I know there's no way to get > them to match) I'm still not sure what the best method is. > > - John_H I would tend to agree with you, but this should be easily measurable. Using a DDR flop with D1 high and D0 low (like a clock driver) you just need to look at the duty cycle. Run the design both ways and check it out...Article: 127340
On Dec 18, 1:43 pm, Gabor <ga...@alacron.com> wrote: > > I would tend to agree with you, but this should be easily measurable. > Using > a DDR flop with D1 high and D0 low (like a clock driver) you just need > to > look at the duty cycle. Run the design both ways and check it out...- I'm more concerned with the input side, actually. I was thinking the output duty cycle could get distorted just by the nature of the output drivers but I figure LVDS would do a decent job of balancing the line. Would a 1-up measurement really give an idea of what works better overall? I've read some of the Xilinx info (some a bit old) that suggests the duty cycle distortion can add from 90 ps (Virtex-II many years ago) to 400ps (Spartan-3, more recent) but the "DCD" timing numbers referred to no longer show up in the DC&Switching section of the data sheet. For any one design, different clock loading will result in different clock skew between a CLKFX and CLKFX180 signal unless the I/O happen to be unaffected by clock loading elsewhere on the chip. Measurements may start to give me an idea of what's going on in the silicon but I would sure appreciate some concrete information. At least in parts with differential clocks (assuming it propagates past one family) won't have duty cycle distortion issues. Bleah. - John_HArticle: 127341
<wxy0624@gmail.com> wrote in message
news:e43ec1f2-8d3b-47c2-b9a2-1a6fc17c7d8c@b1g2000pra.googlegroups.com...
On 12月17日, 下午6时13分, "Symon" <symon_bre...@hotmail.com> wrote:
> <wxy0...@gmail.com> wrote in message
>
> news:58990fd1-be0d-410e-85ad-37765935953b@e6g2000prf.googlegroups.com...
>
>
>
>
>
> > Xilinx V4SX35
> > ISE 8.2.03
> > Modelsim
>
> > I got CLKI(300MHz), CLKI_DIV(150MHz) generated through a counter(just
> > a flip_flop) clocked by CLKI, both clocks connect to BUFG. Then I use
> > CLKI to sample data generated byCLKI_DIV(width=160bit), simulation
> > result in some warnings which said setuptime is not enough during
> > sampling. How can I constraint PAR to get enough setuptime?
>
>
> Dear Whoever,
> Use CLKI to clock _all_ the synchronous elements. Use CLKI_DIV as the
> clock
> enable for all the synchronous elements you were going to clock with
> CLKI_DIV.
> HTH., Syms.- 隐藏被引用文字 -
>
> - 显示引用的文字 -
> Thanks!
>
> That is exactly what I am doing now, and the FPGA is working properly
> under lab condition.
Read Symon's suggestion again....what you've described is NOT what he
suggested.
> It just a warning during simulation.
And that 'warning' will turn into an intermittent functional failure for you
eventually.
> I just worry about when the environment, for example, the voltage
> changes, the temperature changes,
> or something like that.
Temp will do it. Try cold spraying or heat gunning your 'working properly
under lab condition' FPGA and is likely that it will fail.
> I move the flipflop which generate CLKI_DIV to change the phase
> relationship between the two clocks,
> but it's time consuming and not effective.
That's because the correct approach is to have one clock in your design and
have your the divided down clock be used as a clock enable. Example:
process(CLKI)
begin
if rising_edge(CLKI) then
if (CLKI_DIV = '0') then
-- Whatever you have that is currently clocked
-- by 'CLKI_DIV' goes here.
end if;
end if;
end process;
> Is there some other methods to achieve the setup time?
Yes, see above and get rid of all of your processes that are clocked by
'CLKI_DIV'
> Some kind of constraints in the UCF file?
Only if you want to have a flaky design
Kevin Jennings
Article: 127342I posted code to your message in comp.lang.vhdl. Have a look at it. Regards, JKArticle: 127343
John_H wrote: > > What's the best way to clock DDR flops from a DCM? > In V2, the two clock net scheme works best. When doing this, I've avoided the DCM jitter by running the clock into a DIFF_OUT global buffer variant without using a DCM. I haven't measured this in S3E. > > Much of the early DDR information suggested using the 0 and 180 degree > outputs from the DCM. I never considered this a good design practice > because the outputs are going through different BUFGs with different > clock loads on each net resulting in a designed-in skew that would > compromise the DDR sampling windows. I've used isolated clock nets for just the DDR I/O, with a different net for the global logic clock, in my past V2 designs; this requires intentional LOCing of the global buffers to the clock sites having shared routing resources. I posted about this a while back on the "DIFF_OUT Buffer Example" thread, see this thread and the comments in the code example: http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/367adf3537689ded > > Is there any real evidence one way or the other to suggest that one of > these approaches is better than the other? > I measured V2 clock duty cycle and DDR setup/hold, without any DCM involvement, by using a two channel HP8133A and forwarding the clock and DDR data output back out another LVDS pair to a 20 GHz sampler. > > Don't newer parts route differential clocks for single global clock > nets now? Or is that just the Virtex series? My designs are V4 and V5 have differential global routes, but in V4 some of the regional resources are still single ended ( and because V4 can't directly clock a global spline from a local clock input having the best DDR I/O performance, some creative clocking workarounds are required to avoid needing the same clock on a global & local input) BrianArticle: 127344
> Yes, see above and get rid of all of your processes that are clocked by > 'CLKI_DIV' Thanks! But do you mean to let all logic clocked by CLKI, meanwhile use CLKI_DIV as a clk_enable? That would make all the logic run at 300MHz. I want to use concurrent logic to achieve lower clock frequency, that is why I am using CLKI_DIV. Even if V4SX55 can run at 300MHz, I don't think it's a good idea. And I still have to worry about the skew of CLKI_DIV, and the phase relationship beteen the 2 clocks, which is the main problem. You know, if use BUFG to drive CLKI_DIV, the phase relationship is hard to control, If not, the skew will be a huge problem. These 2 problems are all I got right now, and they are still there! I really wanna know your solution in detail.Article: 127345
On Dec 18, 3:31 pm, John Adair <g...@enterpoint.co.uk> wrote:
> Aravind
>
> Most people that has these modules only got them with the new revision
> release in the last few weeks. The first revison batch was snapped up
> very rapidly by only 2 or 3 customers taking numbers of units. Those
> modules ended up in some interesting projects. A lot of modules have
> shipped in the last few weeks so the same question in a few weeks
> should get a better response.
>
> If you have any questions in the meantime I'll be happy to answer then
> in the newsgroup or you can place a query with my team on our
> "support" email - @enterpoint.co.uk.
>
> We should be adding some applications and related information over the
> coming months as soon as we get a little less busy. We have launched a
> lot of things this month and January will bring some more. The FAQ
> page on this product will appear soon although most questions so far
> have been on the I/O available on the PGA (220 from my memory) and on
> MicroBlaze applications.
>
> John Adair
> Enterpoint Ltd.
>
> On 18 Dec, 06:18, aravind <aramos...@gmail.com> wrote:
>
>
>
> > Hi,
> > I'm planning to purchase the Darnaw1 PGA module (http://www.enterpoint.co.uk/moelbryn/darnaw1.html). for my audio console
> > project. Has anyone worked on this module?
>
> > About my audio console project.
> > It basically consists of a system controller (ARM7/ARM9) and an FPGA.
> > The FPGA contains all the periperals like, S/PDIF receiver, ATA HDD
> > interface, FTDI Vinculum USB host interface, multichannel audio codec,
> > STA013 mp3 player interface etc. The FPGA will be connected to the
> > ARM7/9 through External Bus Interface (EBI).All the peripherals on the
> > FPGA will be mapped to some address on the EBI of ARM. Since there are
> > a lot of peripherals on the FPGA i'll require a lot of logic and I/O
> > too. I cannot afford to design/fabricate 6 layer + boards required for
> > such an FPGA. Darnaw looks like the perfect solution.
>
> > Aravind.- Hide quoted text -
>
> - Show quoted text -
Hi,
I visited your web shop (http://www.enterpoint.co.uk/store/
erol.html#1X0), I can't seem to find the darnaw module in it and also
can u give details on shipping and payment modes. the shipping, tax
etc pages are all blank. Thanks
Aravind.
Article: 127346
Below and at http://nishioka.com/misc/lwip-1.2.0.patch are the changes
to use lwip 1.2.0 with Xilinx EDK 9.1 or earlier
It seems the lwip api has changed slightly.
I don't have EDK 9.2 so I don't know what version of lwip is included,
but EDK 9.1 uses lwip 0.7.2.
Alan Nishioka
alan@nishioka.com
$ diff -Naur xemacif.c-orig xemacif.c
--- xemacif.c-orig 2007-12-18 22:59:57.893585600 -0800
+++ xemacif.c 2007-12-18 12:01:08.242739200 -0800
@@ -305,9 +305,12 @@
struct pbuf *p,
struct ip_addr *ipaddr)
{
+ err_t status;
+
XEmacIf_Config *xemacif_ptr = xemacif_ptr = netif_ptr->state;
- p = etharp_output(netif_ptr, ipaddr, p);
+ status = etharp_output(netif_ptr, ipaddr, p);
+ if( status != ERR_OK ) return status;
if (p != NULL) {
/* send the frame */
@@ -329,7 +332,7 @@
struct netif * netif_ptr = (struct netif *) CallBackRef;
XEmacIf_Config * xemacif_ptr;
struct eth_hdr * ethernet_header;
- struct pbuf *p, *q;
+ struct pbuf *p;
xemacif_ptr = netif_ptr->state;
@@ -338,25 +341,19 @@
if (p != NULL) {
ethernet_header = p->payload;
- q = NULL;
switch (htons(ethernet_header->type)) {
case ETHTYPE_IP:
- q = etharp_ip_input(netif_ptr, p);
+ etharp_ip_input(netif_ptr, p);
pbuf_header(p, -14);
netif_ptr->input(p, netif_ptr);
break;
case ETHTYPE_ARP:
- q = etharp_arp_input(netif_ptr, &(xemacif_ptr->ethaddr), p);
+ etharp_arp_input(netif_ptr, &(xemacif_ptr->ethaddr), p);
break;
default:
pbuf_free(p);
break;
}
-
- if (q != NULL) {
- low_level_output(netif_ptr, q);
- pbuf_free(q);
- }
}
return ERR_OK;
Article: 127347Hi All, Our current board already uses a spartan-3. Thats is the reason for trying to fit this in spartan-3. Vertex will involve more cost (211 $ or so for XC4VFX25) hence the reluctance. external add on boards can also be considered. but i did not find any suitable one Thanks all -m.pArticle: 127348
Many thanks Ben, and all others, for these feedbacks ! Robert "Ben Jackson" <ben@ben.com> a 閏rit dans le message de news: slrnfmgfiv.2jbv.ben@saturn.home.ben.com... > On 2007-12-17, Robert Lacoste <> wrote: >> >> We are going to start a project in which we will need to use the hardware >> MAC Ethernet module in a Virtex 5 for high speed transferrs (around >> 400KB/s) >> through 1000BT. I'm looking for experience feedbacks : Anyone who has >> used >> tihs module without a third-party TCP/IP stack (as we have in mind to > > We generated data by writing directly to a V4 hard_temac. We didn't > configure it manually, though, there was other passthrough traffic from > a plb_temac. The Linux driver configured the MAC (but there aren't that > many host bus registers to set if you want to use only hard_temac). > Remember you need a valid header, and an OS network stack is doing a lot > behind the scenes to handle routing, arping, etc. If this is going off- > board, you will need something to configure your PHY, too. > > It's actually easy to inject data into a hard_temac that's also being > driven by a plb_temac because the interface lets the hard_temac (or your > wedge) flow control the upstream. So you can block the plb_temac (as > if you were a slow interface, or experiencing collisions) while you drive > the hard_temac with your data. > >> Difficulties ? Quality of the documentation ? Virtex 4 >> vs 5 ? Reference designs or good sources of information ? > > There are appnotes covering all of it. If you avoid 10/100 (and go 1000 > only) things are simpler (MII vs GMII reverses some of the clock flow). > > -- > Ben Jackson AD7GD > <ben@ben.com> > http://www.ben.com/Article: 127349
Aravind It should be on the shop website soon but meantime the way to order is to email the sales team at "boardsales" email - @enterpoint.co.uk. 2 options on international postage (1) Low cost international (national postal services) GBP=A310+ VAT (if applicable) for most countries =A315 a few of the more distant countries like Australia. (2) FEDEX usually between GBP=A322-35 + VAT depending on country. With christmas post rush option (1) may be slow at the moment. Normally about 1 week ship time. FEDEX to US and Europe is usually next day, or day after if we miss ship cutoff time. Other countires vary a little. I think the worst was a ship to India of about 5 days. Pricing of the DW1-1200EC-128M-16M (XC3S1200E, commercial temp, GBP=A370 + VAT) in a one off quantity. That's in stock currently. There was a newsletter offer running but I think that finished at the end of last week and we have a different offer running now. The DW1-1600EC-128M-16M version I think our stock flew off the shelf very quickly and is currently out of stock. we are trying to schedule another batch in assembly for mid-end January but that's subject to finding some assembly capacity(our line is already very loaded for Jan) and silicon arriving when it should. Please note that Friday this week is the last shipping day for 2007. Our planned first ship in January is on the 7th although we may start shipping a couple of days better than that as there will be people in the office but allocated to a stock check activity. John Adair Enterpoint Ltd. On 19 Dec, 05:05, aravind <aramos...@gmail.com> wrote: > On Dec 18, 3:31 pm, John Adair <g...@enterpoint.co.uk> wrote: > > > > > > > Aravind > > > Most people that has these modules only got them with the new revision > > release in the last few weeks. The first revison batch was snapped up > > very rapidly by only 2 or 3 customers taking numbers of units. Those > > modules ended up in some interesting projects. A lot of modules have > > shipped in the last few weeks so the same question in a few weeks > > should get a better response. > > > If you have any questions in the meantime I'll be happy to answer then > > in the newsgroup or you can place a query with my team on our > > "support" email - @enterpoint.co.uk. > > > We should be adding some applications and related information over the > > coming months as soon as we get a little less busy. We have launched a > > lot of things this month and January will bring some more. The FAQ > > page on this product will appear soon although most questions so far > > have been on the I/O available on the PGA (220 from my memory) and on > > MicroBlaze applications. > > > John Adair > > Enterpoint Ltd. > > > On 18 Dec, 06:18, aravind <aramos...@gmail.com> wrote: > > > > Hi, > > > I'm planning to purchase the Darnaw1 PGA module (http://www.ent= erpoint.co.uk/moelbryn/darnaw1.html). for my audio console > > > project. Has anyone worked on this module? > > > > About my audio console project. > > > It basically consists of a system controller (ARM7/ARM9) and an FPGA. > > > The FPGA contains all the periperals like, S/PDIF receiver, ATA HDD > > > interface, FTDI Vinculum USB host interface, multichannel audio codec,= > > > STA013 mp3 player interface etc. The FPGA will be connected to the > > > ARM7/9 through External Bus Interface (EBI).All the peripherals on the= > > > FPGA will be mapped to some address on the EBI of ARM. Since there are= > > > a lot of peripherals on the FPGA i'll require a lot of logic and I/O > > > too. I cannot afford to design/fabricate 6 layer + boards required for= > > > such an FPGA. Darnaw looks like the perfect solution. > > > > Aravind.- Hide quoted text - > > > - Show quoted text - > > Hi, > I visited your web shop (http://www.enterpoint.co.uk/store/ > erol.html#1X0), I can't seem to find the darnaw module in it and also > can u give details on shipping and payment modes. the shipping, tax > etc pages are all blank. Thanks > > Aravind.- Hide quoted text - > > - Show quoted text -
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