Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Mar 24, 9:32=A0am, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: [... snip ...] > from your comments it was not so sure, did you actually got it to work > with real hardware? (with older tools)? [... snip ...] Hi Antti, Unfortunately, I'm travelling at the moment so I don't have access to all my files. However, here are the modifications to the configuration image that I made before it was supported in software. From testing, there are separate controls to enable ColdBoot and WarmBoot images. I think that the current software release enables both ColdBoot and WarmBoot (i.e., I don't see any way to individually enable or disable the controls). Here is an annotated bitstream snippet that shows some of the control bits. This is the =93control=94 header loaded at the start of the configuration image and must be located at address 0. It contains the ColdBoot and WarmBoot controls plus the start vector addresses for each of the four possible configuration images. WARNING: These are old notes so it=92s probably worth re-testing. 7e aa 99 7e ; Synchronization word 92 00 30 ; "30" enables both ColdBoot and WarmBoot, "20" enables just ColdBoot, "10" enables just WarmBoot 01 08 00 00 00 00 00 00 00 ; zero fill to align to 32 bytes boundary 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e aa 99 7e ; Synchronization word starts a 32-byte boundary, Image 0 vector address 92 00 00 44 0b 10 00 00 ; "0b" is the SPI fast read command. The next six hex digits (10 00 00) are the 24-bit starting byte address 01 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e aa 99 7e ; Image 1 vector address 92 00 00 44 0b 20 00 00 01 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e aa 99 7e ; Image 2 vector address 92 00 00 44 0b 30 00 00 01 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e aa 99 7e ; Image 3 vector address 92 00 00 44 0b 30 00 00 ; NOTE: Jumps to same address as Image 2 in this example 01 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Load the following images at the following starting byte addresses (the actual addresses are specified in the control header). 0x10000: Image 0 0x20000: Image 1 0x30000: Image 2 (Image 3 vector also points to this location) I hope this helps. I can try more when I'm back in the office later this week. -- Steve Knapp Prevailing Technology, Inc. www.prevailing-technology.comArticle: 139476
On Mar 31, 4:41=A0pm, hassen.kar...@gmail.com wrote: > Hi, > > 1- Hardware : Generate you bit file whatever how . ---> > system_stub_download.bit > 2- Software : Compile you application ---> application.elf > 3- Use Data2me to put software into bitsream. > Example : > data2mem -bm "system/implementation/system_bd" -bt > "system_stub_download.bit" -bd "system\SDK_projects\application\Debug > \application.elf" tag microblaze_0 =A0-o b system_bram_initialised.bit you did not read the OP, same as me. he only concern is COREGEN related memories not those made with EDK or hand crafted there are no problems with EDK there are no problems when memories are used with ISE (no EDK flow) as long as they are not done with Coregen as per Xilinx AR, ISE 8.1 was the last version of ISE that supported coregen generated memories and data2mem AnttiArticle: 139477
On Mar 27, 10:45=A0pm, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > let me explain in more detail: > > if I use LatticeMico32 for commercial product targetting Xilinx, > Altera.. > or > if I use MicroBlaze(tm) clone on Altera, Lattice > > then I suppose it may get unwanted attention, or if not it will get > absolute nil support from the vendors where soft-core marketed > by direct competitor is used. How does anyone know what's inside your FPGA if you don't advertise it? Who's to know that you've ported Mico32 to Xilinx? Sssssh, don't tell anyone. As for support, well, that's always an issue. > C- Compiler for PicoBlaze, well it can be used for some test to prove > it generates code, but PicoBlaze is so crippled that the solution is > not much useable. Just too small code space. PicoBlaze was meant to be small. If you exceed the 1k code space, then you might wish to consider a different "processor." For small state- machine things, PicoBlaze actually works quite well. Maybe one day Ken Chapman will update his compiler, though. Things like hard-coded name/ path for the template really suck. Yes, I've complained on the Xilinx forum, but that complaint is ignored. So I use the pBlaze IDE instead. Works well enough. -aArticle: 139478
On Mar 31, 10:29=A0am, Oliver Faust <oliver.fa...@gmail.com> wrote: > On Mar 30, 9:09=A0pm, czam <csat...@gmail.com> wrote: > > > > > On Mar 30, 4:27=A0pm, Oliver Faust <oliver.fa...@gmail.com> wrote: > > > > Hi, > > > I want to network multiple embedded processors using optical fiber as > > > physical layer. This network is realised with point to point > > > connections. At the moment, the network is established using RS232. T= o > > > get higher data rates (around 100Mb/s) and better protection against > > > EMI the electrical RS232 should be exchanged with optical data > > > transfer. > > > In order to realise this change, I'm searching for a technology > > > similar to Fiber Channel (FC). The only, difficulty with FC is that > > > the speed is too high, the slowest speed for fiber channel is 1Gb/s. > > > Furthermore, fiber channels use sophisticated IO (Xilinx rocket IO) , > > > for cost effectiveness I don't want to invest in these expensive IOs. > > > I looked around on the net for some possible solutions, but fiber > > > channel was the closest solution to my problem I could find. My > > > question is therefore: > > > Did I overlook something? Is there an IP-core or external chip which > > > allows me to establish a 100Mb/s data communication link between two > > > embedded processors using fiber optic. > > > > Thank you in advance for your help. > > > Oliver Faust > > > You can check the TLK family of transceivers from Texas Instruments; > > they exist in different speeds. Apart from a couple of these you will > > need a photodiode and a laser (of course). > > > The chip uses 8b/10b to encode the data, but it is all transparent for > > the user. > > > hope it helps, > > Christos > > Dear Christos, > Thank you for the suggestion. However, a brief glance over the TLK > family of transceivers from Texas Instruments showed me that these are > converters Gbit Ethernet to Fiber Channel. Unless I missed something, > this is too fast for my application. > > Oliver Faust Check the TLK1501. To interface it in an FPGA is really trivial. 1 clock signal, 16 I/Os (for your data) and 2 control pins. Some questions for you to consider: What is the distance you'll need to cover? What is the number of links you'll need to establish? Is reliability a major issue (i.e. protection system)? Regards, ChristosArticle: 139479
I've been fighting XST not to remove duplicate logic I put on purpose to decrease fanout on some nets and I can't find a set of attributes, which would work... I tried "keep" and "noreduce" in combination with MAX_FANOUT, but XST(8.2.03i) seems to just ignore them all. Does anyone know how to force the damn thing to keep the duplicate logic? Thanks, /MikhailArticle: 139480
On Mar 31, 5:10=A0pm, "MM" <mb...@yahoo.com> wrote: > I've been fighting XST not to remove duplicate logic I put on purpose to > decrease fanout on some nets and I can't find a set of attributes, which > would work... I tried "keep" and "noreduce" in combination with MAX_FANOU= T, > but XST(8.2.03i) seems to just ignore them all. Does anyone know how to > force the damn thing to keep the duplicate logic? > > Thanks, > /Mikhail If you run from the ISE GUI, set the following in the Xilinx-specific options tab of the Synthesis properties: Register Duplication: checked Equivalent Register Removal: unchecked Then in the HDL Options tab uncheck "Resource Sharing". This should allow XST to duplicate registers as necessary to reduce fanout as well as to push registers into IOBs if requested. Regards, GaborArticle: 139481
MM wrote:
> I've been fighting XST not to remove duplicate logic I put on purpose to
> decrease fanout on some nets
There is a max_fanout constraint,
but I would just constrain Fmax
and let synthesis work out the details.
-- Mike Treseler
Article: 139482"Mike Treseler" <mtreseler@gmail.com> wrote in message news:49D28BA3.2060601@gmail.com... > > There is a max_fanout constraint, > but I would just constrain Fmax > and let synthesis work out the details. I am in the fine tuning mode. The design is big and I am trying to achieve closure on just a few last nets. /MikhailArticle: 139483
"gabor" <gabor@alacron.com> wrote in message news:0b1d4f4e-1a41-4b89-af04-f01fc08ee36a@v6g2000vbb.googlegroups.com... >If you run from the ISE GUI, set the following in the Xilinx-specific >options tab of the Synthesis properties: > >Register Duplication: checked >Equivalent Register Removal: unchecked > >Then in the HDL Options tab uncheck "Resource Sharing". Thanks. Giving this a try. It must have been Equivalent Register Removal setting! I wish the tools would produce meaningful warnings about the user constraints been overridden! /MikhailArticle: 139484
On 17 Mrz., 09:58, Jaime Andr=E9s Aranguren Cardona
<jaime.arangu...@gmail.com> wrote:
> On 16 Mrz., 17:18, Jaime Andr=E9sArangurenCardona
>
>
>
>
>
> <jaime.arangu...@gmail.com> wrote:
> > On 26 Feb., 23:02, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> > > gabor wrote:
>
> > > (snip)
>
> > > > For Spartan 3 MIG, which is primitive compared to the Virtex 5
> > > > MIG, the order of row vs. bank addressing is not important.
> > > > This is due to the fact that the MIG code only leaves one
> > > > row of one bank active at any time. =A0The column address should
> > > > be your low order address bits for linear addressing. =A0This
> > > > will prevent unnecessary row precharge / activate sequences
> > > > when performing linear access to memory.
>
> > > One that I might try is a video display that also refreshes
> > > the RAM. =A0That is an old trick that might still work.
>
> > > > Also note that
> > > > the least significant bits of the column address are
> > > > incremented inside the memory chip during a burst operation.
> > > > There is no carry out to the upper address bits, so when
> > > > starting a burst you should normally begin at a burst
> > > > boundary to avoid rapping back to previous addresses.
>
> > > I don't expect any burst operations. =A0My first system will
> > > be 8080 based, and I don't believe that the 8080 does bursts.
>
> > > > Be careful when using the MIG top level interface with
> > > > "linear" address. =A0It may be using the least significant
> > > > bits for the bank address (depends on which interface
> > > > typeDDR, DDR2, etc.).
>
> > > -- glen
>
> > Hi guys,
>
> > Going further with the thread, I want to "report" that it seems to be
> > working, but partially. In simulation everything goes fine, both for
> > writing and reading data. I generate a sequence of numbers, fill the
> > memory with it, and then read all the positions back, comparing with
> > the sequence of numbers written. If an error is found, a counter is
> > incremented. At the end of the read sequence, if everything goes fine,
> > one led should glow, if not (even a single mismatch was found, which
> > means the error counter is different to zero) then 6 leds glow.
>
> > I am testing my stuff on an S3E Kit. If I just run the test for a very
> > few rows (say 3), then most of the times the test passes, others it
> > does not. If I run for higher number of rows, then at all times it
> > fails. So, it seems to me that I am getting timing problems. Besides,
> > I have to add that I am not using an external 133 MHz clock to SMA
> > connector, I am using the onboard 50Mhz clock instead and a couple
> > DCMs, one for generating a 100 MHz clock and another one to generate
> > the 90 degree phase shifted clock.
>
> > Reviewing the implementation reports (ISE 10.1 and ISE 9.2), I see
> > that the signal rst_dqs_div does not meet timing (MAX_DELAY 460 ps).
> > Looking into the details of the UCF, I see that this signal, which for
> > the S3E Starter kit is implemented as a loopback, has an assigment to
> > pin P13. I suppose that that is needed because of packaging to IOBs,
> > which is one of the project options for the MIG generated project. Is
> > there a way to make the signal always internal and not look for a
> > physical pin?
>
> > The only way I have found to meet timing constraints was to remove
> > that constraint in the UCF (the one that assigns rst_dqs_div signal to
> > pin P13), but now another problem arises: when generating the
> > bitstream, it fails because DRC is not passed, saying that the signal
> > rst_dqs_div was assigned to bank3 which uses impedance controlled
> > buffers or has Vref requeriments, which rst_dqs_div does not meet.
>
> > How can it be got to work reliably? Even the original project
> > generated by MIG (ver 2.1, ver 2.3) for the S3E Kit, without
> > modifications, fails to meet the timing constraints for signal
> > rst_dqs_div, which is supposed to be a critical timing signal
> > necessary to get the controller working correctly.
>
> > All your comments and suggestion are very welcome.
>
> > Kind regards.
>
> Hi,
>
> I bypassed the DRC test for bitstream generation, but results are even
> worse: now, most of the times it fails.... very seldom passes, even
> for just 3 rows.
>
> Any hint?
>
> Kind regards.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -
Hi,
I am sorry to say that this is FAR from solved... My "checker" does
not work, simply because the cntrl0_data_valid_out signal does not
show valid data in a Post-Translate simulation, whereas in the
Behavioral Simulation it works perfect.
Examining the code in the file (generated from MIG2.3)
xxx_data_read_controller_0.vhd one can see this code:
-- User data valid output signal from data path.
fifo_0_empty <=3D '1' when (fifo0_rd_addr(3 downto 0) =3D
fifo_0_wr_addr_3d(3 downto 0)) else '0';
fifo_1_empty <=3D '1' when (fifo1_rd_addr(3 downto 0) =3D
fifo_1_wr_addr_3d(3 downto 0)) else '0';
read_valid_data_0_1 <=3D ((not fifo_0_empty) and (not
fifo_1_empty));
read_valid_data_1_val <=3D (read_valid_data_0_1);
process(clk90)
begin
if clk90'event and clk90 =3D '1' then
if reset90_r =3D '1' then
u_data_val <=3D '0';
read_valid_data_r <=3D '0';
read_valid_data_r1 <=3D '0';
else
read_valid_data_r <=3D read_valid_data_0_1;
read_valid_data_r1 <=3D read_valid_data_r;
u_data_val <=3D read_valid_data_r1;
end if;
end if;
end process;
There is where the signal is actually generated, the other things are
merely structural connections. However, in the synthesis one get the
following warnings:
WARNING:Xst:2677 - Node <reset90_r> of sequential type is unconnected
in block <data_read0>.
WARNING:Xst:2677 - Node <read_valid_data_1_r> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <read_valid_data_1_r1> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_0> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_1> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_2> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_3> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_4> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_5> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_6> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_7> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_8> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_9> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_10> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_11> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_12> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_13> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_14> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_15> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_0> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_1> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_2> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_3> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_4> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_5> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_6> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_7> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_8> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_9> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_10> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_11> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_12> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_13> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_14> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_15> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_0> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_1> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_2> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_3> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_4> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_5> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_6> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_7> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_8> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_9> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_10> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_11> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_12> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_13> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_14> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_15> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_16> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_17> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_18> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_19> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_20> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_21> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_22> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_23> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_24> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_25> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_26> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_27> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_28> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_29> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_30> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_31> of sequential type is
unconnected in block <data_read0>.
It looks like all what I needed is stripped down from the netlist.
Does someone know how to get rid of this, and make the MIG2.3 DDR
Controller work????
Thanks!
Article: 139485On Mar 30, 4:46=A0pm, Andy Ross <andy.ross...@gmail.com> wrote: > I recently bought a Digilent Nexys 2 board, and after a few days of > research got to the point where I can successfully program it over USB > from a Linux host without the use of a separate (and expensive!) JTAG > interface. =A0Google told me even before I purchased the board that this > is a very common requirement; it seems that I'm not the only one > interested in linux-hosted FPGA development. =A0The pieces to make this > work were all there, happily (see the README in the download below for > details -- the chain of responsibility here is long); it just took > work to assemble them correctly. > > For those interested, I wrote a quick perl script to automate the > process, available at: [url]http://plausible.org/andy/nexys2prog.tar.gz > [/url] > > This wraps the multi-step mess (device detection/configuration, SVF > generation, and JTAG download) as fully as possible, most importantly > by doing the USB bus enumeration and dynamically reprogramming the > Nexys 2 with a patched usb_jtag firmware blob in the script itself. > The user just specifies the Xilinx bitstream file as the sole > argument. > > Installation is as simple as I could make it, requiring only Xilinx > ISE, two binary packages (fxload and libftdi -- both available via apt- > get on Ubuntu Intrepid) and one source install (UrJTAG -- just a > simple "./configure;make;make install" will do). > > Hopefully this will help other newbies with the learning curve. =A0Let > me know if something doesn't work, or if there are questions. Thanks for putting that together! I've been googling unsuccessfully for all that info since buying my Nexsys 2 a few months ago. derp derp derp. EricArticle: 139486
Hi, all. I'm relatively new to the field of digital design, and have completed a few FPGA-based designs, successfully integrated and debugged them. Writing HDL, using vendor tools and performing simulations have been fairly straightforward and within my comfort zone. But now I'm faced with the foreign task of debugging some nasty timing problems, and I'm realizing how little I understand about some fundamental digital design principles, like setup and hold timing, clock skew and jitter, and the like. What books and other resources would you recommend for someone who needs a better understanding of digital design principles, with a special focus on timing concerns? Thanks, The Wondering GnomeArticle: 139487
"Oliver Faust" <oliver.faust@gmail.com> wrote in message news:2f957410-1e66-440f-ac70-ae0e5d83cf1c@k41g2000yqh.googlegroups.com... On Mar 30, 6:55 pm, Tommy Thorn <tommy.th...@gmail.com> wrote: > > You know, the simplest, best tested, _widely_ available, and likely > > cheapest solution is ... (drumroll) 100 Mbps Ethernet. Ethernet is > > very tolerant of EMI, and with Cat 6 cables I seriously doubt you > > could have an issue. > > Fiber is fun (and healthy in your diet), but it just isn't mainsteam > > enough which translates into either high cost or lots of custom > > development. > > Tommy > Dear Tommy, > At the moment I'm in the discovery phase of the project. Slowly, I > understand the point that fiber optics are not mainstream. Fiber > optics are only considered for applications where weight is an issue > and / or EMI resilience. > Oliver Faust There is a 100 Mbps fiber optic Ethernet standard, 100BASE-FX that still exists (of course Gigabit Ethernet gets all the attention these days). I remember we used it to replace FDDI (ugh!) on an aircraft platform that needed fiber optic networking for EMI reasons. Of course we made that change something like 8 years ago but I don't think they've changed it again yet. A quick Google brought up a Broadcom BCM5248 transceiver chip with 8 ports. MartyArticle: 139488
All, Though a long-time Xilinx user, I have yet to try partitions or the updated smartguide feature. I would appreciate your thoughts on these features. Which is best at reducing runtime? Does partitioning really, truly lock the placement and routing? Are there reasons not to use them that aren't at first obvious? Thanks, StephenArticle: 139489
"palvarez" <pabloalvarezsanchez@gmail.com> wrote in message news:cc81f482-560b-4641-8ade-e322a71113c8@37g2000yqp.googlegroups.com... > I received recently the Vita 57 standard. I would like to congratulate > the Vita team that has written it. It is a beautiful standard that > many people have been waiting for since a long time. On the first page > there is a warning stating that the dedicated clock distribution pins > from Carrier to Mezzanine (C2M) were going to be replaced by Mezzanine > to Carrier (M2C) pins. This means that if you ever want to feed a > clean, stable, low jitter you will have to pass through the FPGA using > standard differential IOs. > > Adding more M2C pairs is not really helpful as standard FPGA IOs can > already be routed to the DCM reference clock input without major > problems (please correct me if I am wrong). On the other hand the > added jitter by the FPGA will be a liming factor for high accuracy > data acquisition applications that do not receive their reference > clock directly on the FMC front panel. > > I would like to know the FPGA community opinion. Who knows? If we give > the right reasons perhaps the Vita 57 working group could change their > mind after all. As a systems engineer, I can't speak to all the details and I'm just getting familiar with some of the discussion on FMC. I can say that clock synchronization and time distribution is a pet concern of mine. Considering the front panel, I'm not sure how the vendors are going to implement the granddaughter cards regarding clocking...I'm interested in high speed DACs versus ADCs and I haven't seen any announced in FMC yet. Right now, I have a group of 8 boards each with a PMC card that has an FPGA and a couple DACs on them. The initialization and synchronization process on the DACs (Analog Devices AD9857s) is such that I can't get much better than 40 ns alignment between the multiple boards (grr!). I'd like to see a solution that wrings this out better; the 8 boards are fed a 1PPS discrete from a distribution amplifier that should provide less than 0.5 ns skew across the multiple boards. There are also separate phase locked 10 MHz signals going into all of them. All kinds of opportunities for mischief (i.e., 8 independent PLL chips running 409.6 MHz clocks off the 10 MHz). On the other hand, reliably routing 200 MHz clocks from one PMC to multiple others across a VME P2 connections sounds like trouble as well. So, even when you get your clocks from the front panel (losing precious real estate) there can be issues. A good standardized solution would benefit a lot of us. Can the FPGAs possibly run IEEE 1588 to at least get rid of the 1PPS discretes? What's the transmission quality on those M2C and C2M pins? Could they send 10MHz sine waves without adding too much noise? Sorry if this is too much churn and not enough solution...it's just nice to vent to a group that understands some of this. MartyArticle: 139490
On Mar 23, 4:45=A0pm, Antti <Antti.Luk...@googlemail.com> wrote: > I just wonder ;) > > the FREE is not so free actually... all infos say theColdFirecore is > free, and no royalties > but the free license is only for Cyclone III, for all other devices > the license is 10k + 0.02 royalty > > also what is strange there seems to be no download for the free > version :( > > Antti ok, I no longer wonder New project New SOPC component Select ColdFire processor Close Set toplevel ports Click run flow no errors, configuration file for CIII generated unfortunatly this almost all I can say, the agreements I had to sign to get the free core prohibit almost everything except breathing. AnttiArticle: 139491
On Mar 31, 6:07=A0pm, Prevailing over Technology <steve.kn...@prevailing- technology.com> wrote: > On Mar 24, 9:32=A0am, "Antti.Luk...@googlemail.com" > > <Antti.Luk...@googlemail.com> wrote: > > [... snip ...] > > > from your comments it was not so sure, did you actually got it to work > > with real hardware? (with older tools)? > > [... snip ...] > > Hi Antti, > > Unfortunately, I'm travelling at the moment so I don't have access to > all my files. =A0However, here are the modifications to the > configuration image that I made before it was supported in software. > From testing, there are separate controls to enable ColdBoot and > WarmBoot images. =A0 I think that the current software release enables > both ColdBoot and WarmBoot (i.e., I don't see any way to individually > enable or disable the controls). > > Here is an annotated bitstream snippet that shows some of the control > bits. =A0This is the =93control=94 header loaded at the start of the > configuration image and must be located at address 0. =A0It contains the > ColdBoot and WarmBoot controls plus the start vector addresses for > each of the four possible configuration images. =A0WARNING: =A0These are > old notes so it=92s probably worth re-testing. > > 7e aa 99 7e =A0; Synchronization word > 92 00 30 =A0 =A0 ; "30" enables both ColdBoot and WarmBoot, "20" enables > just ColdBoot, "10" enables just WarmBoot Hi Steve thanks a lot for the reply, unfortunatly my testing show different results: 92 00 30 Cold+Warm enabled 92 00 10 Cold+Warm enabled 92 00 20 -- DOES NOT CONFIGURE AnttiArticle: 139492
On Apr 1, 6:19=A0am, "Marty Ryba" <martin.ryba.nos...@verizon.net> wrote: > "palvarez" <pabloalvarezsanc...@gmail.com> wrote in message > > news:cc81f482-560b-4641-8ade-e322a71113c8@37g2000yqp.googlegroups.com... > > > > > I received recently the Vita 57 standard. I would like to congratulate > > the Vita team that has written it. It is a beautiful standard that > > many people have been waiting for since a long time. On the first page > > there is a warning stating that the dedicated clock distribution pins > > from Carrier to Mezzanine (C2M) were going to be replaced by Mezzanine > > to Carrier (M2C) pins. This means that if you ever want to feed a > > clean, stable, low jitter you will have to pass through the FPGA using > > standard differential IOs. > > > Adding more M2C pairs is not really helpful as standard FPGA IOs can > > already be routed to the DCM reference clock input without major > > problems (please correct me if I am wrong). On the other hand the > > added jitter by the FPGA will be a liming factor for high accuracy > > data acquisition applications that do not receive their reference > > clock directly on the FMC front panel. > > > I would like to know the FPGA community opinion. Who knows? If we give > > the right reasons perhaps the Vita 57 working group could change their > > mind after all. > > As a systems engineer, I can't speak to all the details and I'm just gett= ing > familiar with some of the discussion on FMC. I can say that clock > synchronization and time distribution is a pet concern of mine. Consideri= ng > the front panel, I'm not sure how the vendors are going to implement the > granddaughter cards regarding clocking...I'm interested in high speed DAC= s > versus ADCs and I haven't seen any announced in FMC yet. Right now, I hav= e a > group of 8 boards each with a PMC card that has an FPGA and a couple DACs= on > them. The initialization and synchronization process on the DACs (Analog > Devices AD9857s) is such that I can't get much better than 40 ns alignmen= t > between the multiple boards (grr!). I'd like to see a solution that wring= s > this out better; the 8 boards are fed a 1PPS discrete from a distribution > amplifier that should provide less than 0.5 ns skew across the multiple > boards. There are also separate phase locked 10 MHz signals going into al= l > of them. All kinds of opportunities for mischief (i.e., 8 independent PLL > chips running 409.6 MHz clocks off the 10 MHz). On the other hand, reliab= ly > routing 200 MHz clocks from one PMC to multiple others across a VME P2 > connections sounds like trouble as well. > > So, even when you get your clocks from the front panel (losing precious r= eal > estate) there can be issues. A good standardized solution would benefit a > lot of us. Can the FPGAs possibly run IEEE 1588 to at least get rid of th= e > 1PPS discretes? What's the transmission quality on those M2C and C2M pins= ? > Could they send 10MHz sine waves without adding too much noise? > > Sorry if this is too much churn and not enough solution...it's just nice = to > vent to a group that understands some of this. > > Marty there was 3GS/S FMC ADC board at Embedded AnttiArticle: 139493
Hi, In few of the protocols (e.g. USB), there is an 8b10b and then there is line encoding. Since one of the purpose of 8b10b is to create enough 1&0 transitions, why is there a separate line encoding after 8b10b? Am I missing something RegardsArticle: 139494
there will be no MAX-III, and how the "followup" Flash FPGA/CPLD from Altera would be is something mr B from Altera didnt really want to reveal at Embedded... But after checking out the FREE ColdFire v1 core that can be fully integrated with SOPC, and is completly free for Cyclone III, I can now belive that that the new Altera Flash FPGA will really have hardened ColdFire core. I just hope they have learned from the mistakes with MAX-II, and will include user writeable flash blocks like they are available in Lattice XP2. AnttiArticle: 139495
Hi, From the datasheets, it is looks like the only major difference between DCM and PLL is that PLL additionally does jitter filtering. Rest of the features are present in both these macros. So what decides whether one should use a PLL or DCM in FPGA. The following are the common features present in both DCM and PLL: 1) frequency synth 2) deskew 3) frequency div Additionally DCM can also do phase shift. Regards, SharanArticle: 139496
On 1 Apr., 16:01, Sharan <sharan.basa...@gmail.com> wrote: > Hi, > > From the datasheets, it is looks like the only major difference > between DCM and PLL is that PLL additionally does jitter filtering. > Rest of the features are present in both these macros. So what decides > whether one should use a PLL or DCM in FPGA. > > The following are the common features present in both DCM and PLL: > 1) frequency synth > 2) deskew > 3) frequency div > > Additionally DCM can also do phase shift. PLL's do that too. DCM's have a higher potential for failures due tu their state-machine behaviour. For Example EMI could disturb some clocks getting into a DCM locking up and you need a systen reset. Analog PLL's are more tolerant about that and especially if you want to have deterministic jitter-fitering you are lost with the DCM. I would always chose a good analog PLL over DCM.Article: 139497
"Sharan" <sharan.basappa@gmail.com> wrote in message news:6374ea0e-4cdb-474a-9cd6-df68f8252302@v15g2000yqn.googlegroups.com... > Hi, > > From the datasheets, it is looks like the only major difference > between DCM and PLL is that PLL additionally does jitter filtering. > Rest of the features are present in both these macros. So what decides > whether one should use a PLL or DCM in FPGA. > > The following are the common features present in both DCM and PLL: > 1) frequency synth > 2) deskew > 3) frequency div > > Additionally DCM can also do phase shift. > > Regards, > Sharan PLL's have a higher potential for failures due tu their non-state-machine behaviour. For Example EMI could disturb some clocks getting into a PLL phase detector and you get a lock loss. Digital DCM's are more tolerant about that and especially if you want to have deterministic operation that is not component value dependent you are lost with the PLL. I would always chose a good DCM over analog PLL.Article: 139498
On Mar 31, 7:45=A0pm, wondering.gn...@gmail.com wrote: > Hi, all. > > I'm relatively new to the field of digital design, and have completed > a few FPGA-based designs, successfully integrated and debugged them. > Writing HDL, using vendor tools and performing simulations have been > fairly straightforward and within my comfort zone. But now I'm faced > with the foreign task of debugging some nasty timing problems, and I'm > realizing how little I understand about some fundamental digital > design principles, like setup and hold timing, clock skew and jitter, > and the like. > > What books and other resources would you recommend for someone who > needs a better understanding of digital design principles, with a > special focus on timing concerns? > > Thanks, > The Wondering Gnome I've found the latest Xilinx Timing Constraints User Guide to be invaluable. www.xilinx.com/itp/xilinx10/books/docs/timing_constraints_ug/timing_constra= ints_ug.pdfArticle: 139499
"Symon" <symon_brewer@hotmail.com> wrote:
>
>"Sharan" <sharan.basappa@gmail.com> wrote in message
>news:6374ea0e-4cdb-474a-9cd6-df68f8252302@v15g2000yqn.googlegroups.com...
>> Hi,
>>
>> From the datasheets, it is looks like the only major difference
>> between DCM and PLL is that PLL additionally does jitter filtering.
>> Rest of the features are present in both these macros. So what decides
>> whether one should use a PLL or DCM in FPGA.
>>
>> The following are the common features present in both DCM and PLL:
>> 1) frequency synth
>> 2) deskew
>> 3) frequency div
>>
>> Additionally DCM can also do phase shift.
>>
>> Regards,
>> Sharan
>
>PLL's have a higher potential for failures due tu their non-state-machine
>behaviour.
>
>For Example EMI could disturb some clocks getting into a PLL phase
>detector and you get a lock loss.
>
>Digital DCM's are more tolerant about that and especially if you want
>to have deterministic operation that is not component value dependent you
>are lost with the PLL.
>
>I would always chose a good DCM over analog PLL.
Now I'm confused :-)
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
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