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 Sep 4, 7:54=A0am, "Antti.Luk...@googlemail.com" <antti.luk...@googlemail.com> wrote: > On Sep 4, 5:45=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > > > On Sep 4, 2:57=A0am, Uwe Bonnes <b...@elektron.ikp.physik.tu- > > > darmstadt.de> wrote: > > > Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > On Sep 3, 1:45=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > >http://shop.trenz-electronic.de/catalog/product_info.php?products_= id=3D... > > > > > > first S6 boards arrived today, so its finally there(here)! > > > > > > well well well the DIP modules from OHO are also orderable now! > > > > > I had them reviewed in the brain a few month ago, nice to see > > > > > them released and online > > > > > >http://shop.trenz-electronic.de/catalog/default.php > > > > > > Antti > > > > > brain issue August is out too :)http://groups.google.com/group/an= tti-brain/files?hl=3Den > > > > The SP601 started shipping in volume last week. =A0I've been waitin= g for > > > > an Antti post saying that you had yours as I thought that I saw a p= ost > > > > that you had ordered one. :-) > > > > I know that there were ordering/delivery problems in the past with > > > > Spartan-3 boards, but you won't see any of those issues this time > > > > around. > > > > With Digikey, the SP601 is is on status "Call"... > > > -- > > > Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu= -darmstadt.de > > > > Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt > > > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------- Hi= de quoted text - > > > > - Show quoted text - > > > I was actually a bit surprised to see non-Xilinx distributors selling > > the SP601. =A0The first deliveries should be to customers that had pre- > > ordered with our major distributors, Avnet/Insight/Memec/Silica, > > NuHorizons and TED. Independent resellers are likely lower on the > > priority ladder for shipments. > > > Ed McGettigan > > -- > > Xilinx Inc. > > Trenz ist Xilinx Alliance Partner und ich dachte die durfen die Xilinx > produkte offiziel auch verkaufen? > opla :) sprachbarriere... > > Trenz Electronic GmbH is Xilinx Alliance Partner, and has been selling > Xilinx AND Digilent boards > for a long time, so I assumed they are authorized to resell Xilinx > board products? > > Antti- Hide quoted text - > > - Show quoted text - I did not mean to imply that Trenz or Digilent were not authorized to sell the SP601. I was just surpised that they did this.Article: 142876
On Sep 3, 4:30=A0pm, 2G <soar2mor...@yahoo.com> wrote:
> On Sep 3, 11:42=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
>
>
>
>
> > On Sep 3, 8:47=A0am, 2G <soar2mor...@yahoo.com> wrote:
>
> > > On Sep 2, 6:55=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > > > On Sep 2, 11:49=A0am, 2G <soar2mor...@yahoo.com> wrote:
>
> > > > > On Sep 2, 11:10=A0am, Muzaffer Kal <k...@dspia.com> wrote:
>
> > > > > > On Wed, 2 Sep 2009 10:43:27 -0700 (PDT), 2G <soar2mor...@yahoo.=
com>
> > > > > > wrote:
>
> > > > > > >I have a TI TLK2501 SERDES connected to a Virtex-5 on an ML507=
. The V5
> > > > > > >is loading the recovered clock signal with an apparent impedan=
ce of 50
> > > > > > >ohms (measured by the voltage drop across a series resistor). =
This is
> > > > > > >dropping the voltage swing of the signal in half. We have trie=
d a
> > > > > > >different input pin with no change. We then added a buffer wit=
h no
> > > > > > >change. The ucf for that input is:
>
> > > > > > >NET "RX_CLK" LOC =3D "G15" | IOSTANDARD =3D LVCMOS25;
>
> > > > > > >This is not happening to any of the other inputs from the SERD=
ES.
>
> > > > > > >Any ideas as to what is going on?
>
> > > > > > Did you check the board schematics? This signal seems to be con=
nected
> > > > > > to the CPLD also which might be causing the issue you see.
>
> > > > > > --
> > > > > > Muzaffer Kal
>
> > > > > > DSPIA INC.
> > > > > > ASIC/FPGA Design Services
>
> > > > > >http://www.dspia.com
>
> > > > > Yes, we are aware of that. We previously used AJ32 and had the sa=
me
> > > > > problem. We used it because it was the only global clock input
> > > > > available (ISE kept complaining about using that input for a cloc=
k
> > > > > source). If need be, we can isolate the CPLD and LED from that li=
ne
> > > > > (we removed the LED and got no change).
>
> > > > > We just tried rerouting that signal to the USER_CLK after removin=
g the
> > > > > oscillator (X1). This greatly improved the signal quality, but
> > > > > requires a flying wire off of our mezzanine board to make the
> > > > > connection.- Hide quoted text -
>
> > > > > - Show quoted text -
>
> > > > How are you physically connecting the TLK2501 to the ML507?
>
> > > > Ed McGettigan
> > > > --
> > > > Xilinx Inc.- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > The TLK2501 is on a mezzanine board that interconnects thru the
> > > expansion headers (J4-7).- Hide quoted text -
>
> > > - Show quoted text -
>
> > Looking back at your posts you started out using AJ32, HDR1_46, and
> > then switched to G15, GPIO_LED_2, and both of these have an issue with
> > "dropping the voltage in half" for the RX_CLK output from the TLK2501.
>
> > AJ32 is in Bank 13 and is connected to the VCCO_EXP supply and is not
> > GC or CC clock input pin. =A0Did you set the VCCO_EXP supply to 2.5V
> > using the J20 jumpers? =A0Is AK32, HDR1_48, used on the TLK2501 board?
>
> > G15 is in Bank =A01 is connected to VCC2V5 this is a GC clock input, bu=
t
> > it is also connected to the input of the CPLD and the signal integrity
> > will be reduced. Is G16, GPIO_LED_3 used on the TLK2501 board?
>
> > Have you verified that the problem isn't on the TLK2501 board?- Hide qu=
oted text -
>
> > - Show quoted text -
>
> Thanks for the reply.
>
> I checked and it was set to 3.3V, so we changed it to 2.5V and got the
> same SI problems, but the bit error went away (due no doubt to the
> change in threshold levels). The clock signal itself looks terrible:
> its low level is raised to 1.32 V (the high level is 2.5 V), with a
> 0.15 V glitch on the rising edge at the mid point.
>
> AK32 is used for RXD<8>.
>
> We have isolated the clock signal on the TLK2501 board and it looks
> fine. We tried using a different input entirely (HDR1_2, H33) and got
> the same results.
>
> I generated the IBIS file for this design and noted that the same IO
> standard, LVCMOS25_S_2, is used for all inputs from the TLK2501, yet
> the SI problem is exclusive to RX_CLK.
>
> The buffer used, an SL74LVC8T245, is capable of sinking 8 mA with a
> 2.5 V supply while keeping Vol to 0.3 V max. Doing the math, this
> implies there is an equivalent pull-up of about 33 ohms on that line!
>
> Tom- Hide quoted text -
>
> - Show quoted text -
What you are seeing should not be happening so something must be
wrong. I ran a check verification on a ML507 and everything is
working as I expect them to work. A couple of things for you to
check.
1) Is this a standard Xilinx ML507 with a FX70T part?
2) Without your module plug in to the ML507 please verify the
following resistance measurements:
Powered-Off
GND to HDR1_46 =3D 1Mohm
GND to HDR1_48 =3D 1Mohm
2V5 to HDR1_46 =3D 1Mohm
2V5 to HDR1_48 =3D 1Mohm
Powered-on - But not configured
GND to HDR1_46 =3D 45Mohm
GND to HDR1_48 =3D 45Mohm
2V5 to HDR1_46 =3D 25Kohm (weak pullups enabled)
2V5 to HDR1_48 =3D 25Kohm (weak pullups enabled)
3) With your design loaded in the FX70T verify the following voltage
measurements
HDR1_46 =3D 0V
HDR1_48 =3D 0V
If you get similar results as the above then the cause is not from the
ML507 and the problem must be on your TLK2501 module.
Since the RX_CLK is moving between 1.32V and 2.5V this would indicate
that there is strong pullup (33-50ohm according to your posts) to 2.5V
and there isn't anything on the ML507 that should cause this.
Ed McGettigan
--
Xilinx Inc.
Article: 142877On Fri, 4 Sep 2009 07:45:31 -0700 (PDT), johnp wrote: > The real problem I see is that no matter what the > language, at some point you have to deal with > clock domain crossing, meta-stability, setup/hold >issues, logic depth, etc. Indeed so. But none of those things is in any significant way affected by your choice of design entry language. However, I agree that... > Neither language can eliminate these traps. A > newbie who comes into h/w design from a > s/w background probably doesn't appreciate > how tricky these problems can be. That, too, is unquestionably true. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ My advocacy of VHDL over Verilog for RTL design, which is of course quixotic, has much more to do with coding style and re-use concerns. Although SystemVerilog has added some nice features for re-use (packages, typedefs, array query functions) it still has nothing that even comes close to the power and elegance of VHDL's unconstrained array types and dynamic elaboration of subprograms, and the consequent ability to write highly generic subprograms that can be used in a huge variety of designs. If the comparison is with vanilla Verilog, VHDL simply leaves it lying in the dirt. Verilog advocates just don't go there; they get their re-use in other ways that don't depend on Verilog's weaknesses, but instead make use of scripting languages and other non-Verilog tools. I can't see why that is a good idea when VHDL gets it right anyway. Other things that VHDL gets right: the distinction between variables and signals, which sweeps away the need for all that "blocking vs. nonblocking" style-guidance BS in Verilog; the ability to execute arbitrary procedural code at elaboration time, allowing you to use the full power of the language to parameterize your designs; absence of arbitrary limitations on the data type of a port; elaboration-time assertions to check that a parameterizable module has been deployed correctly. And ALL of that has been usable since the very start of VHDL, unlike Verilog which grafted on some of the better design features in its 2001 language revision. Elaboration-time assertions have only this year been added to SystemVerilog, and aren't yet available for use. On the other side of the debate, SystemVerilog adds a raft of interesting new RTL-friendly features: "unique" and "priority" qualifiers on conditionals (although the 2005 definition was somewhat flawed, prompting some significant fixes in the upcoming SV-2009 standard); specialized process templates (always_comb, etc) for modeling RTL designs; shorthand port connection using .*; packed structs and unions; type parameterization. Every one of those things *could* be added to VHDL, but most VHDL folk don't really see the point because VHDL already allows you to do the same things in other ways. Finally, there's the one feature in SystemVerilog that really promises to revolutionize the way we think about RTL design: the interface construct. VHDL has nothing to match it. Interfaces should allow us to write designs that are generic in ways that have never before been accessible. But, as I've argued in public on a number of occasions, interfaces in SV are broken and simply don't do what's needed for truly powerful re-use. (There are non-RTL uses of interfaces that work just fine; it's the design applications that bother me.) ~~~~~~~~~~~~~~~~~~~~~~~~~~ OK, I've said it. Probably more than I should have said. All the above is strictly my personal musings, to be greeted with the usual ridicule. Of course I'm fully aware that the overwhelming majority of ASIC designs, and a good proportion of FPGA designs, are done in Verilog; that situation is unlikely ever to shift in favour of VHDL. And it's worth emphasising once again that my rant is entirely related to RTL design; I find SystemVerilog much more flexible for testbenches than VHDL. But I hope that what I've said might help to lift the discussion one level above the schoolyard arguments we hear so often: "Verilog is like C", or "Verilog lets you write designs with fewer lines of code, so there will be fewer bugs", or whatever. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 142878
Brian Drummond wrote: > The "libusb" driver from rmdir.de works well for me under Linux (OpenSuse 11) > natively (no Windows required) with Parallel Cable IV. Works fine with both > Impact and Chipscope. > > I also tried the Xilinx recommended "libusb" which apparently will work with > their USB programming cables, but doesn't support the parallel cables. I have installed Ise WebPack 10.1 on a 32-bit Linux system, and the driver they supply with the package does support the Parallel Cable III. They have a restriction that only licensed versions of Ise can be used on 64-bit Linux systems, unless you know how to hack some libraries. JonArticle: 142879
Hi, i'm doing this project using FPGA devices. I have to generate higher output frequencies from the propagation delays using a Digital clock manager. Can anyone pls help. If I get the code, nothing like it. Thanks. --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 142880
What should I look at for information about designing pipelined interfaces between multiple producers and multiple consumers in an environment where the amount of time the consumer takes to perform an operation is not constant? Say I'm designing HDL to draw Mandelbrot sets; I have a small block which takes a pixel position as input and, between 8 and 260 cycles later, gives an output as to what colour the pixel should be. 260 cycles * VGA resolution * 200MHz = 2.5 frames per second; not fast enough. Obviously I could instantiate sixteen copies of the block and have sixteen pixel-position-generator units talking to it. But then I need a rather awkward unit between the parallel part and the frame buffer, which can take up to sixteen [location,pixel] inputs each cycle and queue them up to write to the single frame buffer; I don't know what this is called or what its internal design would look like. I assume that it's not possible to design one that can keep up under all circumstances, so I'd need to propagate a please-wait-the-queue-is-full signal back down the system, and this is starting to sound nightmarishly close-coupled enough that I'm sure clever electronics designers have a much better way to do it. If my screen is small enough I could have one sub-frame buffer (as a dual-port block RAM) per Mandelbrot-set unit, and have the frame-buffer-managing unit read out from those in rotation; but if the sub-frames don't all fit on the chip this doesn't work. I'm also very unsure what the right thing to do is if the producer is a CPU; for operations that take a long time, I'd raise an interrupt when the job is done and let the CPU pick up the answer, and the software interface is to hand over a callback function which gets called by the interrupt handler, but I can't see how to stop the software from getting terribly convoluted in that case (since instead of a loop to issue the requests, I have to arrange for the callback function itself to figure out what the next request to issue should be, and the simple 'do these N things' concept gets divided among three functions scattered across the code), and I don't know if there's something better to do in the case where the operation generally takes a length of time comparable to the interrupt latency. TomArticle: 142881
Thomas Womack wrote: > Obviously I could instantiate sixteen copies of the block and have > sixteen pixel-position-generator units talking to it. But then I need > a rather awkward unit between the parallel part and the frame buffer, > which can take up to sixteen [location,pixel] inputs each cycle and > queue them up to write to the single frame buffer; I don't know what > this is called or what its internal design would look like. I assume > that it's not possible to design one that can keep up under all > circumstances, A simple architecture would be to start all 16 calculations in parallel. The parallel units signals ready. If AND all ready signals = 1, then loop over the 16 outputs and write it to the framebuffer. No problem to keep up under all circumstances. Backdraw of this simple design: If one unit needs the maximum time, meanwhile all other units are twiddling their thumbs when they are finished. > so I'd need to propagate a > please-wait-the-queue-is-full signal back down the system, and this is > starting to sound nightmarishly close-coupled enough that I'm sure > clever electronics designers have a much better way to do it. I think what you are searching for is "bus arbitration". There are other interesting ideas for distribution many tasks to simple CPU elements. Take a look at the CUDA architecture of NVIDIA, maybe this can give you some ideas you can use (but I think you have to beware of patents, if it is a commercial project), or the Cell CPU architecture. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142882
On Sep 4, 5:31=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > Finally, there's the one feature in SystemVerilog > that really promises to revolutionize the way we > think about RTL design: the interface construct. > VHDL has nothing to match it. =A0Interfaces should > allow us to write designs that are generic in ways > that have never before been accessible. =A0But, as > I've argued in public on a number of occasions, > interfaces in SV are broken and simply don't do > what's needed for truly powerful re-use. =A0(There > are non-RTL uses of interfaces that work just fine; > it's the design applications that bother me.) I've been pining for what seems like forever to bring to VHDL a primitive yet powerful sort of interface that would be completely at home in RTL: user definable, custom port modes for record data types. Defining a record for an interface is so easy and intuitive, but the fact that, currently, the entire record (and every element in it) must be of one mode IN, OUT, INOUT, etc., means the only effective way to use them is to make the entire record port inout. This restricts the leaf-level types within the record to being resolved types, and requires a lot of fiddling around with default assignments to 'Z', (std_logic), etc. If we had a way to define custom modes for record types, on an element by element basis, this perverse use of resolved types and default driven values would not be necessary. Of course, a way to define more than one custom mode for most types will be necessary (e.g. master vs slave endpoints on a bus). But once the modes were defined, you could implement records with any data types you wanted (integer, enum, boolean, etc.), even other record types (with their own defined custom modes). The task of "hooking up" large structures with complex interfaces would be simplified tremendously, as would the ability to plumb these complex interfaces through multiple levels of hierarchy via "conduits" through which we can virtually pull any kind of cable or fiber we might want, and even change our mind without massive rework. I've used this record technique to plumb generics throughout a design with great success (largely because generics are always inputs). I'm not a language expert, and I'm not sure what the syntax would need to look like for defining these custom modes, but it sure seems like a simple addition to the language that would reap huge dividends. AndyArticle: 142883
On 05 Sep 2009 09:42:16 +0100 (BST), Thomas Womack wrote: >Say I'm designing HDL to draw Mandelbrot sets; I have a small block >which takes a pixel position as input and, between 8 and 260 cycles >later, gives an output as to what colour the pixel should be. 260 >cycles * VGA resolution * 200MHz = 2.5 frames per second; not fast >enough. >Obviously I could instantiate sixteen copies of the block and have >sixteen pixel-position-generator units talking to it. But then I need >a rather awkward unit between the parallel part and the frame buffer, It may help to think of the compute units as a farm. If you can split up the work into pieces small enough that they can live entirely on the FPGA (which, for Mandelbrot, is easy: a single image line can fit comfortably in on-chip RAM) then you could have a single job dispatcher that works its way along the line, issuing each pixel in sequence to the first free functional unit that it finds. Then you have sixteen (or whatever) "done" flags, and a simple round-robin polling gadget that checks each flag in turn and, as soon as it finds a "done" compute unit, pulls the data from that and writes it to the line buffer. The corresponding compute unit is then free and will soon be given work by the dispatcher. When the whole line is done, you can write it to external memory and switch over the compute farm to work on a second line buffer while the write-to-memory is in progress. This approach scales reasonably well to increasing numbers of compute units. Obviously it's considerably harder when the work spans more than one pixel, but it's still worth the effort of breaking up the work so that you are operating on one or more complete image lines stored on-chip. Each line can then be written to the external frame store efficiently as one or more bursts. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 142884
On Sat, 5 Sep 2009 06:28:28 -0700 (PDT), Andy wrote:
>I've been pining for what seems like forever to bring to VHDL a
>primitive yet powerful sort of interface that would be completely at
>home in RTL: user definable, custom port modes for record data
>types.
Didn't they put something a bit like that into VHDL-2008?
Shame on me, I've not yet got fully up-to-speed with that.
>If we had a way to define custom modes for record types, on an element
>by element basis, this perverse use of resolved types and default
>driven values would not be necessary. Of course, a way to define more
>than one custom mode for most types will be necessary (e.g. master vs
>slave endpoints on a bus). But once the modes were defined, you could
>implement records with any data types you wanted (integer, enum,
>boolean, etc.), even other record types (with their own defined custom
>modes).
All this is true, and it's one of the things that SV interfaces
and modports do reasonably well. However, the real power of
interfaces comes from their ability to import and export
functionality (subprograms) to/from their connected modules.
I'm not aware of any move towards that sort of thing in VHDL.
It doesn't really work quite right in SV either, but at least
they had a shot at it.
>The task of "hooking up" large structures with complex interfaces
>would be simplified tremendously, as would the ability to plumb these
>complex interfaces through multiple levels of hierarchy via "conduits"
>through which we can virtually pull any kind of cable or fiber we
>might want, and even change our mind without massive rework.
Absolutely. One of my ultimate goals is the creation of
bus-agnostic peripherals: here's my DMA device; if I connect
it to a Wishbone interface, it automatically inherits a
Wishbone bus control state machine from that interface;
connect it to AHB and it likewise inherits AHB control
machinery... There was a nifty paper on that idea in the
early days of SV:
Jensen, Kruse and Ecker.
SystemVerilog in Use: First RTL Synthesis
Experiences with Focus on Interfaces.
SNUG Europe 2004.
But it never really got off the ground - too many
language-inadequacy hurdles to overcome.
I guess there's no point in sighing for what might
have been....
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 142885On 5 Sep., 10:42, Thomas Womack <twom...@chiark.greenend.org.uk> wrote: > Say I'm designing HDL to draw Mandelbrot sets; I have a small block > which takes a pixel position as input and, between 8 and 260 cycles > later, gives an output as to what colour the pixel should be. =A0260 > cycles * VGA resolution * 200MHz =3D 2.5 frames per second; not fast > enough. > > Obviously I could instantiate sixteen copies of the block and have > sixteen pixel-position-generator units talking to it. =A0But then I need > a rather awkward unit between the parallel part and the frame buffer, > which can take up to sixteen [location,pixel] inputs each cycle and > queue them up to write to the single frame buffer; No, you don't. If you have N processing units (PU) that perform computations that require more than N clock cycles it is obviously sufficient to issue one task per clock cycle and retire one task per clock cycle. To avoid idle cycles at the units each unit should be able to buffer one result that waits to be retired and it also should be able to store the instructions for the next task while still busy with the previous task. There is one scheduler that selects a PU with empty instruction register and issues an instruction to it and an arbiter that selects a PU with valid result in its output buffer and writes it wherever it should be written to. If you have very high clock rates or a very large number of PUs arbitration and scheduling might not be possible in a single cycle. You can than use a linear array of PUs. Instructions are fed to the left end of the array. Each unit either consumes the instruction of forwards it to it neighbor to the right. On the outputs each PU forwards the result from the left neighbor, or its own result if none is presented by the neighbor. This approach can achieve very high clock rates because only local routing is required and the decision making is extremely simple. Kolja Sulimma www.cronologic.deArticle: 142886
Sure, VHDL is better for a new user. Writing the same thing again and again and again and again helps you remember it. JonArticle: 142887
ISE Version is 10.1.03i, and target chip is xc5vlx50t-1ff665. On the customized board, when powered up, I can initialize the JTAG chain and read the FPGA status register as follows: CRC error : 0 Decryptor security set : 0 DCM locked : 1 DCI matched : 1 End of startup signal from Startup block : 0 status of GTS_CFG_B : 0 status of GWE : 0 status of GHIGH : 0 value of MODE pin M0 : 1 value of MODE pin M1 : 1 Value of MODE pin M2 : 1 Internal signal indicates when housecleaning is completed: 1 Value driver in from INIT pad : 1 Internal signal indicates that chip is configured : 0 Value of DONE pin : 0 Indicates when ID value written does not match chip ID: 0 Decryptor error Signal : 0 System Monitor Over-Temperature Alarm : 0 startup_state[18] CFG startup state machine : 0 startup_state[19] CFG startup state machine : 0 startup_state[20] CFG startup state machine : 0 E-fuse program voltage available : 0 SPI Flash Type[22] Select : 1 SPI Flash Type[23] Select : 1 SPI Flash Type[24] Select : 1 CFG bus width auto detection result : 0 CFG bus width auto detection result : 0 Reserved : 0 BPI address wrap around error : 0 IPROG pulsed : 0 read back crc error : 0 Indicates that efuse logic is busy : 0 And if I download a small FPGA design (a counter driving LEDs) through JTAG, it works well and the chipscope could report the device temperature and core voltage as expected. Now the problem comes. When I download the MIG2.3 based DDR2 example design into FPGA, the download always completed successfully with CRC error, the impact reports as bellow: CRC error : 1 Decryptor security set : 1 DCM locked : 1 DCI matched : 1 End of startup signal from Startup block : 1 status of GTS_CFG_B : 1 status of GWE : 1 status of GHIGH : 1 value of MODE pin M0 : 1 value of MODE pin M1 : 1 value of MODE pin M2 : 1 Internal signal indicates when housecleaning is completed: 1 Value driver in from INIT pad : 1 Internal signal indicates that chip is configured : 1 Value of DONE pin : 1 Indicates when ID value written does not match chip ID: 1 Decryptor error Signal : 1 System Monitor Over-Temperature Alarm : 1 startup_state[18] CFG startup state machine : 1 startup_state[19] CFG startup state machine : 1 startup_state[20] CFG startup state machine : 1 E-fuse program voltage available : 1 SPI Flash Type[22] Select : 1 SPI Flash Type[23] Select : 1 SPI Flash Type[24] Select : 1 CFG bus width auto detection result : 1 CFG bus width auto detection result : 1 Reserved : 1 BPI address wrap around error : 1 IPROG pulsed : 1 read back crc error : 1 Indicates that efuse logic is busy : 0 INFO:iMPACT:2217 - Error shows in the status register, CRC Error bit is NOT 0. INFO:iMPACT:2219 - Status register values: INFO:iMPACT - 1111 1111 1111 1111 1111 1111 1111 1110 INFO:iMPACT:579 - '2': Completed downloading bit file to device. Match_cycle = 2. INFO:iMPACT - '2': Checking done pin....done. '2': Programmed successfully. PROGRESS_END - End Operation. Elapsed time = 14 sec. Once the bit file is downloaded into the FPGA, the JTAG chain never works again unless power off the board and power on again. Also chipscope reports goes incorrectly, the temperature will be 230.3 degree with VCCINT=2.997V and VCCAUX=2.997V. The chip temperature will dramatically increase to a very high level and I have to cut off the power. However the FPGA did not get broken, next time when powered on, I can still download the small design to drive the LEDs. And if I download the MIG2.3 DDR2 bit file, the phenomena remains. The problem is very hard to resolve since I could not keep the crashed FPGA status for a long time, because the chip will become very hot and probably damage itself, I could not measure different power rails at that time. Now I could not get any information except the value of status register reported by impact. Will this problem be related with DCI? How could I narrow down the problem.Article: 142888
Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote:
>On Sat, 5 Sep 2009 06:28:28 -0700 (PDT), Andy wrote:
>
>>I've been pining for what seems like forever to bring to VHDL a
>>primitive yet powerful sort of interface that would be completely at
>>home in RTL: user definable, custom port modes for record data
>>types.
>
>Didn't they put something a bit like that into VHDL-2008?
>Shame on me, I've not yet got fully up-to-speed with that.
>
>>If we had a way to define custom modes for record types, on an element
>>by element basis, this perverse use of resolved types and default
>>driven values would not be necessary. Of course, a way to define more
>>than one custom mode for most types will be necessary (e.g. master vs
>>slave endpoints on a bus). But once the modes were defined, you could
>>implement records with any data types you wanted (integer, enum,
>>boolean, etc.), even other record types (with their own defined custom
>>modes).
>
>All this is true, and it's one of the things that SV interfaces
>and modports do reasonably well. However, the real power of
>interfaces comes from their ability to import and export
>functionality (subprograms) to/from their connected modules.
>I'm not aware of any move towards that sort of thing in VHDL.
>It doesn't really work quite right in SV either, but at least
>they had a shot at it.
>
>>The task of "hooking up" large structures with complex interfaces
>>would be simplified tremendously, as would the ability to plumb these
>>complex interfaces through multiple levels of hierarchy via "conduits"
>>through which we can virtually pull any kind of cable or fiber we
>>might want, and even change our mind without massive rework.
>
>Absolutely. One of my ultimate goals is the creation of
>bus-agnostic peripherals: here's my DMA device; if I connect
>it to a Wishbone interface, it automatically inherits a
>Wishbone bus control state machine from that interface;
That is probably why *both* VHDL and Verilog need to be dropped and
replaced by something else. Like C# is replacing C/C++.
--
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!"
--------------------------------------------------------------
Article: 142889Jon wrote: > Sure, VHDL is better for a new user. Writing the same thing again and > again and again and again helps you remember it. I will admit that most vhdl users do not use functions and procedures for this, but it is possible -- both for synthesis and simulation code. -- Mike TreselerArticle: 142890
On Sep 5, 9:40=A0am, Jon <j...@beniston.com> wrote: > Sure, VHDL is better for a new user. Writing the same thing again and > again and again and again helps you remember it. > > Jon To what are you referring that you must write over and over again? AndyArticle: 142891
On 4 Sep., 09:19, "HT-Lab" <han...@ht-lab.com> wrote: > "glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message > > news:h7p82b$mgn$1@naig.caltech.edu... > > > > > Andy <jonesa...@comcast.net> wrote: > > (snip on verilog and VHDL) > > > < (Other than my personal bias) : Given the differences between coding > > < for SW and coding for HW, VHDL is better at keeping a new user from > > < making some ignorant mistakes. A new designer with a SW background is > > < more likely to make typical "SW" mistakes in a language that looks > > < more like the SW he is used to. Sometimes keeping the syntax apart > > < helps in this regard. On the other hand, if one's SW background is in > > < ada, you could make exactly the same argument in favor of verilog ;^) > > > I don't agree, but I believe it could be personal preference. > > For one, I did some logic design with TTL gates before learning > > verilog, so I know how to think in terms of logic. > > > Verilog isn't really that much like C. =A0There are people using > > C as an HDL, and I completely agree that is a bad idea. > > Don't be too quick to dismiss C for HDL, there are lots of companies that > develop algorithms in Matlab/C/C++/SC and then pass it on to a poor engin= eer to > "quickly" translate into VHDL/Verilog. Then a month later they require th= e same > algorithm but 5 times faster or with a "subtle change" which normally res= ults > (requires) a costly redesign. For those applications you really want to u= se an > untimed language like C/C++ and use a tool (CatapultC/BlueSpec/ > Forte/Synfora/etc...) to do all the design exploration (resource mapping/= adding > pipelines/concurrency/etc) for you. > > Given the progress these tools are making (most can now also handle contr= ol path > as well) and the amount of money companies like Intel/AMD are pouring int= o > sequential to concurrent research I wouldn't be surprise if the future of= RTL is > neither VHDL nor Verilog..... There are very good reasons to use imperative languages for rapid prototyping and synthesizing complex algorithms to hardware. BUT: We in the world would anyone want to use a language with as many side effects as C (or even worse C++) for that purpose????? If you like C syntax that much use Java or C#-. Siemens was doing Java to netlist before the System-C hype but they were approached with stupid arguments like "the AWT is sooo slow" which is completely irrelevant as for hardware prototyping one uses none of the APIs that usually come with the language and also does not use the garbage collector. IIRC C does not even have a formal memory model, how is one supposed to do formal verification on C code? KoljaArticle: 142892
I removed the MIG DDR2 example logic in my design and replace with hard wire signals like below: assign ddr2_a = 13'b1111111111111; assign ddr2_ba = 2'b11; assign ddr2_cs_n = 4'b1111; assign ddr2_odt = 4'b0000; assign ddr2_dm = 8'b11111111; assign ddr2_ras_n = 1; assign ddr2_cas_n = 1; assign ddr2_we_n = 1; assign ddr2_cke = 0; ............. And I found that if I add the DCI IOs like dq/dqs_p/dqs_n, the FPGA will crash definitely and once I removed these DCI-class IOs, the FPGA will function normally and I can read back the temperature after programming. Therefore I can draw the conclusion that this problem is highly related to DCI. Any suggestions?Article: 142893
"Kolja" <ksulimma@googlemail.com> wrote in message news:63b90383-9f00-4df2-a320-60b832e94382@g19g2000yqo.googlegroups.com... On 4 Sep., 09:19, "HT-Lab" <han...@ht-lab.com> wrote: > "glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message > > news:h7p82b$mgn$1@naig.caltech.edu... > ..snip > Given the progress these tools are making (most can now also handle control > path > as well) and the amount of money companies like Intel/AMD are pouring into > sequential to concurrent research I wouldn't be surprise if the future of RTL > is > neither VHDL nor Verilog..... > >There are very good reasons to use imperative languages for rapid >prototyping and >synthesizing complex algorithms to hardware. >BUT: >We in the world would anyone want to use a language with as many side >effects >as C (or even worse C++) for that purpose????? If you like C syntax >that much use Java or C#-. I don't understand this statement. > >Siemens was doing Java to netlist before the System-C hype but they >were approached >with stupid arguments like "the AWT is sooo slow" which is completely >irrelevant as >for hardware prototyping one uses none of the APIs that usually come >with the language >and also does not use the garbage collector. >IIRC C does not even have a formal memory model, how is one supposed >to do formal verification on C code? Formal verification (ACE) for C is nothing new, however, I suspect that throwing a bunch of assertions at VHDL/Verilog is a lot easier than doing the same for C code. Hans www.ht-lab.comArticle: 142894
I have found something else. I used 4 DDR2 components to make a 64bits wide memory width. If I only add serveral DCI IOs, e.g. the dqs_p/dqs_n pair (16 DCI IOs), FPGA works fine. However if I add 64 bits wide DQ, the FPGA crashes. if I add only half of the DQ bus (32 bits wide), the FPGA will work for a while and then crashes. and the JTAG chain remains functional after programming, and becomes unaccessable after dozens of seconds. So does this means I could not have 64 SSTL18_II_DCI and 16 DIFF_SSTL18_II_DCI in a Virtex5 LXT50 FF665 package?Article: 142895
vcar wrote: > I have found something else. > I used 4 DDR2 components to make a 64bits wide memory width. If I only > add serveral DCI IOs, e.g. the dqs_p/dqs_n pair (16 DCI IOs), FPGA > works fine. > However if I add 64 bits wide DQ, the FPGA crashes. > if I add only half of the DQ bus (32 bits wide), the FPGA will work > for a while and then crashes. and the JTAG chain remains functional > after programming, and becomes unaccessable after dozens of seconds. > > So does this means I could not have 64 SSTL18_II_DCI and 16 > DIFF_SSTL18_II_DCI in a Virtex5 LXT50 FF665 package? Theoretically this should be possible. You might run into SSO problems and active cooling might be neccessary, but there's no restriction on the number of IOs using DCI that I know of. Maybe you have a power supply problem. DCI uses quite a lot of power. Have you measured your supply voltages in the three cases you mentioned? Are they stable and at nominal value in all cases? Does maybe the IO-supply drop when all DCI are enabled? A drop in the IO supply voltage should not impact the internal functionality, though, neither should the JTAG interface be affected (unless the IO bank 0 with the configuration pins uses the same voltage). cu, SeanArticle: 142896
Mike Treseler <mtreseler@gmail.com> wrote:
>Jon wrote:
>> Sure, VHDL is better for a new user. Writing the same thing again and
>> again and again and again helps you remember it.
>
>I will admit that most vhdl users do not
>use functions and procedures for this,
>but it is possible -- both for synthesis
>and simulation code.
Just for fun: google for code for a priority encoder. 9 out of 10
write it as seperate equations for each condition. If you create a
procedure, its only 3 lines of code!
--
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!"
--------------------------------------------------------------
Article: 142897Nico Coesel wrote: > Like C# is replacing C/C++. ROTFL!!! You're taking the p*ss, right??? Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 142898
Today, Sigasi proudly announces Mac OS X support for Sigasi HDT, an Intelligent Development Environment (IDE) for VHDL. Sigasi HDT is built upon the widely accepted Eclipse platform and contains an ultra-fast VHDL parser and compiler. As a result, the tool fully understands a design in terms of VHDL concepts. The tool is currently available in a public beta program. From user feedback, we learned that there is a significant interest in Mac OS X support. Sigasi HDT for Mac OS X is immediately available for download, please visit http://www.sigasi.com/start.Article: 142899
On Fri, 04 Sep 2009 17:35:28 GMT, Nico Coesel wrote: >I still see no difference between the development flow for a cpu and >an FPGA. Its all about idea -> specification -> implementation -> >verification / testing. That's true so far. Indeed, it's unfortunate that so few HDL folk buy in to the good ideas about that flow that have been developed (at cost of great pain) by the software community over the past few decades. >The only real difference is that a CPU executes a program >sequentially and an FPGA executes its program in parallel. Neither of those things is necessarily true these days. Parallelism is endemic in compute platforms today (although most programmers are still in denial about it) and it's easy enough to get an FPGA to have sequential behavior of various kinds. But it is clearly true that FPGA users must be prepared to work with very fine-grained parallelism, which is precisely why they have programming languages (VHDL, Verilog) that explicitly support it. Conventional imperative languages have no explicit support for fine- grained parallelism; therefore, it falls to the tools to infer parallelism from the sequential code. Sometimes tools can do that very well; most times they need heavy hints; occasionally they completely fail. It's not surprising that many of us are reluctant to support a wholesale move to procedural languages for hardware design. As I've said before many times, I completely fail to understand why there has been so little take-up in the software community of languages that explicitly support parallel execution (occam, Ada...). The usual argument is that it's easier to reason about sequential than about concurrent programs. That argument is, in my opinion, baseless; in the languages I've mentioned, concurrency is well-managed and easy to reason about. Ho hum. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.
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