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 2006-12-11, mjl296@hotmail.com <mjl296@hotmail.com> wrote:
> vits wrote:
>
>> ok I will put it like this..
>> always @(*)
>> begin
>> a=b;
>> @(posedge clk);
>> c=a;
>> end
>> What does it mean.
>
> It is a bad idea. Synthesis tools will reject this code, and although a
> simulator will process it, nobody reading your code will be able to
> understand or maintain it.
>
> To help you understand it, I'll explain what it does in simulation...
>
> 1) It waits for an event on a, b or clk
> 2) It sets a=b
> 3) It waits for a rising clock edge
> 4) It sets c=a
> 5) It loops from step 1.
I thought this was an intriguing question because I did not know how
@(*) deals with clk in the case above so I looked it up in
the Verilog standard. (IEEE Std 1364-2005 to be exact, section
9.7.5.)
It turns out that @(*) should add all (net and variable) identifiers to
the sensitivity list unless at least one of the following is true:
* It is only used as a destination for an assignment
* It only appears in a wait or event expression.
The following is an example from the standard:
always @* begin // equivalent to a(b)
@(i) kid = b; // i is not added to @*
end
So the example above should be modified as follows:
1) It waits for an event on a or b
I could also note that the version of Modelsim I'm using (6.2b) does seem
to add identifiers in event expressions to the sensitivity list
unfortunately.
/Andreas
Article: 113376
Hi,
yesterday I solved a problem while integrating the embedded TEMAC of an
V4FX60 with an RGMII PHY after some try and error. The solution works,
but I wonder why it didn't before. Ah, I'm using ISE 8.1i for synthesis
(and using EDK for the build process..).
That's what happened:
At first I used coregen to generate a template of an embedded EMAC with
RGMII connection in Verilog and integrated it in my design. Only
receiving worked, sending resulted in frames with bad fcs at the
receiver. I studied afterwards the EDK implementation of the hard_temac
core (because this example works). Now I have the following situation:
I/O-Signals are defined as:
output [3:0] RGMII_TXD_RISING_0;
output [3:0] RGMII_TXD_FALLING_0;
output RGMII_TX_CTL_RISING_0;
output RGMII_TX_CTL_FALLING_0;
input [3:0] RGMII_RXD_RISING_0;
input [3:0] RGMII_RXD_FALLING_0;
input RGMII_RX_CTL_RISING_0;
input RGMII_RX_CTL_FALLING_0;
The following code snippet works:
wire [7:0] rgmii_rxd;
wire [7:0] rgmii_txd;
assign rgmii_rxd = {RGMII_RXD_FALLING_0, RGMII_RXD_RISING_0};
assign RGMII_TXD_FALLING_0 = rgmii_txd[7:4];
assign RGMII_TXD_RISING_0 = rgmii_txd[3:0];
EMAC v4_emac
(
...
.PHYEMAC0RXCLK (RGMII_RXC_0),
.PHYEMAC0RXD (rgmii_rxd),
.PHYEMAC0RXDV (RGMII_RX_CTL_RISING_0),
.PHYEMAC0RXER (RGMII_RX_CTL_FALLING_0),
.PHYEMAC0MIITXCLK (),
.EMAC0PHYTXCLK (),
.EMAC0PHYTXD (rgmii_txd),
.EMAC0PHYTXEN (RGMII_TX_CTL_RISING_0),
.EMAC0PHYTXER (RGMII_TX_CTL_FALLING_0),
.PHYEMAC0COL (1'b0),
.PHYEMAC0CRS (1'b0),
...
);
The following code can only receive data, but sending doesn't work:
EMAC v4_emac
(
...
.PHYEMAC0RXCLK (RGMII_RXC_0),
.PHYEMAC0RXD ({RGMII_RXD_FALLING_0,
RGMII_RXD_RISING_0}),
.PHYEMAC0RXDV (RGMII_RX_CTL_RISING_0),
.PHYEMAC0RXER (RGMII_RX_CTL_FALLING_0),
.PHYEMAC0MIITXCLK (),
.EMAC0PHYTXCLK (),
.EMAC0PHYTXD ({RGMII_TXD_FALLING_0,
RGMII_TXD_RISING_0}),
.EMAC0PHYTXEN (RGMII_TX_CTL_RISING_0),
.EMAC0PHYTXER (RGMII_TX_CTL_FALLING_0),
.PHYEMAC0COL (1'b0),
.PHYEMAC0CRS (1'b0),
...
);
Interestingly receiving works in both cases. In my naive thinking I
would believe that both snippets are semantically identical. So where
did I make an error? Are there some optimizations which changed the
behaviour?
Thanks,
Christian.
Article: 113377Ok, you might be right, so some more info: The first board is industrial und unchangeable. I only can add some VHDL to the exisiting design and do a resynthesis. There is enough room in the fpga to add a uart or anything I like. The second board does not really exist, but I have no time to built something special. so an eval board will/must do. The boards of course yet sharing nothing, neither ground nor VDD. But of course I can add gnds for example. The first board contains a xilinx spartan, the second possibly too . I am free in this. Well, of course I had the idea to take a big fpga and warp the existing fpga design to put into the new board for evaluation - but this gives me only limited information. I have also to use the surounding hardware of the industrial board. Does it suit, to only use a simple IO-Line, GND and a clock to come out with 100MHz ? Can I use a kind of twisted pair? Or better someting shaped as an IDE-cable? I am currently not yet familiar with these "differntial pairs" - I only know about using symmetrical wiring from analog domain. Is this similar ?Article: 113378
alterauser schrieb: > Ok, you might be right, so some more info: > > The first board is industrial und unchangeable. I only can add some > VHDL to the exisiting design and do a resynthesis. There is enough room > in the fpga to add a uart or anything I like. The second board does not > really exist, but I have no time to built something special. so an eval > board will/must do. > > The boards of course yet sharing nothing, neither ground nor VDD. But > of course I can add gnds for example. The first board contains a xilinx > spartan, the second possibly too . I am free in this. > > Well, of course I had the idea to take a big fpga and warp the existing > fpga design to put into the new board for evaluation - but this gives > me only limited information. I have also to use the surounding hardware > of the industrial board. > > Does it suit, to only use a simple IO-Line, GND and a clock to come out > with 100MHz ? > Can I use a kind of twisted pair? Or better someting shaped as an > IDE-cable? > > I am currently not yet familiar with these "differntial pairs" - I only > know about using symmetrical wiring from analog domain. Is this similar > ? look at Ken Chapmans ultra compact UART macros a very simple solution would be using LVDS half-duplex UART you only need 2 wires and can transmit maybe at above 100MHz bit rates AnttiArticle: 113379
"Antti" <Antti.Lukats@xilant.com> wrote in message news:1165917906.074970.206210@l12g2000cwl.googlegroups.com... > look at Ken Chapmans ultra compact UART macros > a very simple solution would be using LVDS half-duplex UART > you only need 2 wires and can transmit maybe at above 100MHz bit rates The OP would need to be careful about the very low common-mode voltage capability of LVDS in an 'industrial' setting. IME you need a decent ground connection between TX and RX with LVDS, and will then need to arrange things so that the ground doesn't inadverantly start to carry its share of the hundreds of amps which are often flying around the place. But I suspect that if a 100MHz inter-board connect is really needed, someone more experienced is going to be needed to help with it... Will From removethisthenleavejea@replacewithcompanyname.co.uk Tue Dec 12 05:13:54 2006 Path: newssvr25.news.prodigy.net!newsdbm05.news.prodigy.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!newsfeed.news2me.com!newsfeed.icl.net!newsfeed.fjserv.net!colt.net!nntp.theplanet.net!inewsm1.nntp.theplanet.net!pe2.news.blueyonder.co.uk!blueyonder!proxad.net!proxad.net!news.clara.net!wagner.news.clara.net!monkeydust.news.clara.net!proxy02.news.clara.net From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk> Newsgroups: comp.arch.fpga References: <1165867148.44940.0@iris.uk.clara.net> <1165873229.990241.88560@73g2000cwn.googlegroups.com> <elkk3a$4op$1@online.de> Subject: Re: Tarfessock1 Date: Tue, 12 Dec 2006 13:13:54 -0000 Lines: 22 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-RFC2646: Format=Flowed; Response X-Complaints-To: abuse@clara.net (please include full headers) X-Trace: 62e1330022b7504412241d2032e323607e35204063d8339301c78010457eab1b NNTP-Posting-Date: Tue, 12 Dec 2006 13:14:03 +0000 Message-Id: <1165929243.24752.0@proxy02.news.clara.net> Xref: prodigy.net comp.arch.fpga:124449 Hillls actually. "Antti Lukats" <antti@openchip.org> wrote in message news:elkk3a$4op$1@online.de... > "Andy Peters" <Bassman59a@yahoo.com> schrieb im Newsbeitrag > news:1165873229.990241.88560@73g2000cwn.googlegroups.com... >> John Adair wrote: >>> First picture of Tarfessock1, minus cardbus covers, now on our website >>> for >>> those that are interested in our little cardbus dual-FPGA development >>> board. >> >> Sorry, gotta ask: how do you come up with these names? >> >> -a >> > stones. > holy stones. > names of holy stones. > From removethisthenleavejea@replacewithcompanyname.co.uk Tue Dec 12 05:20:45 2006 Path: newssvr25.news.prodigy.net!newsdbm05.news.prodigy.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!newsfeed.freenet.de!213.132.189.2.MISMATCH!multikabel.net!feed20.multikabel.net!newshub2.home.nl!newshub3.home.nl!home.nl!border2.nntp.ams.giganews.com!nntp.giganews.com!proxad.net!news.clara.net!wagner.news.clara.net!monkeydust.news.clara.net!proxy02.news.clara.net From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk> Newsgroups: comp.arch.fpga References: <1165867148.44940.0@iris.uk.clara.net> <1165870805.203892.219490@80g2000cwy.googlegroups.com> Subject: Re: Tarfessock1 Date: Tue, 12 Dec 2006 13:20:45 -0000 Lines: 29 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-RFC2646: Format=Flowed; Original X-Complaints-To: abuse@clara.net (please include full headers) X-Trace: 72c0732193e33d25222385ae21104d206c6330a3d016110a336e691c457eacb8 NNTP-Posting-Date: Tue, 12 Dec 2006 13:20:56 +0000 Message-Id: <1165929656.25355.0@proxy02.news.clara.net> Xref: prodigy.net comp.arch.fpga:124450 Picture is ala camera phone so not best image. There will be an update in a few weeks probably for a proper press release. Apologies for those waiting for the board but we have been very overlaoded with cuistomer paid work which always gets priority. Some more interesting things to come shortly that we are sitting on at present. The white square is a deliberate feature to confuse our competitors or is ir? John Adair Enterpoint Ltd. "Tommy Thorn" <tommy.thorn@gmail.com> wrote in message news:1165870805.203892.219490@80g2000cwy.googlegroups.com... > John Adair wrote: >> First picture of Tarfessock1, minus cardbus covers, now on our website >> for >> those that are interested in our little cardbus dual-FPGA development >> board. > > Congrats. I'll take one in a 3S1600E guise, but there's no urgency. > > The picture is blurry! What's under the white square? :-) > > Cheers, > Tommy >Article: 113380
"Alfmyk" <Alfmyk@hotmail.com> wrote in message news:eea0f4e.1@webx.sUN8CHnE... > Hi Clark. > > Thanks for your answer. At the moment in the application where ISRs are present no cache using has been enabled. So I don't think problem should related to it. > > I don't understand very well about interrupt table... I'm using, for the moment, to register the ISR in dynamic mode with the low level function XIntc_RegisterHandler(). I tested also the static mode setting handler function via EDK using software menu and so on... But problem are the same... Please could you explain better what you mean with "...Vector Table on 64 KB boundary.." ? > > Thank you very much. > > Al. In your linker file there is a section called .vectors. This must be on a 64kbyte boundary. For example, I had a design with only 32kbyte block ram at 0xffff8000 and none of the interrupts would work. I found out that I had to increase to 64 kByte and start at 0xffff0000 to get it to work. You may have a similar problem.. Under your linker options you can add -Map myapp.map to generate a map file that will show the addreses of all the variables and sections in your code. .vectors should be the first section in the map so just check where your code starts. -ClarkArticle: 113381
What is the sign-and-magnitude of the following 4's complement number? (Leave answer in base 4). The number: 33333210 (base 4) Hi, Ive been asked the following question and although slightly familary with compure match and storage, i can't figure this. I gather it needs converting Thanks a lot in advance PaulArticle: 113382
cpmetz@googlemail.com wrote:
> Hi,
>
> yesterday I solved a problem while integrating the embedded TEMAC of an
> V4FX60 with an RGMII PHY after some try and error. The solution works,
> but I wonder why it didn't before. Ah, I'm using ISE 8.1i for synthesis
> (and using EDK for the build process..).
>
> That's what happened:
> At first I used coregen to generate a template of an embedded EMAC with
> RGMII connection in Verilog and integrated it in my design. Only
> receiving worked, sending resulted in frames with bad fcs at the
> receiver. I studied afterwards the EDK implementation of the hard_temac
> core (because this example works). Now I have the following situation:
>
> I/O-Signals are defined as:
> output [3:0] RGMII_TXD_RISING_0;
> output [3:0] RGMII_TXD_FALLING_0;
> output RGMII_TX_CTL_RISING_0;
> output RGMII_TX_CTL_FALLING_0;
> input [3:0] RGMII_RXD_RISING_0;
> input [3:0] RGMII_RXD_FALLING_0;
> input RGMII_RX_CTL_RISING_0;
> input RGMII_RX_CTL_FALLING_0;
>
> The following code snippet works:
>
> wire [7:0] rgmii_rxd;
> wire [7:0] rgmii_txd;
>
> assign rgmii_rxd = {RGMII_RXD_FALLING_0, RGMII_RXD_RISING_0};
> assign RGMII_TXD_FALLING_0 = rgmii_txd[7:4];
> assign RGMII_TXD_RISING_0 = rgmii_txd[3:0];
>
>
> EMAC v4_emac
> (
> ...
> .PHYEMAC0RXCLK (RGMII_RXC_0),
> .PHYEMAC0RXD (rgmii_rxd),
> .PHYEMAC0RXDV (RGMII_RX_CTL_RISING_0),
> .PHYEMAC0RXER (RGMII_RX_CTL_FALLING_0),
> .PHYEMAC0MIITXCLK (),
> .EMAC0PHYTXCLK (),
> .EMAC0PHYTXD (rgmii_txd),
> .EMAC0PHYTXEN (RGMII_TX_CTL_RISING_0),
> .EMAC0PHYTXER (RGMII_TX_CTL_FALLING_0),
> .PHYEMAC0COL (1'b0),
> .PHYEMAC0CRS (1'b0),
> ...
> );
>
>
> The following code can only receive data, but sending doesn't work:
>
> EMAC v4_emac
> (
> ...
> .PHYEMAC0RXCLK (RGMII_RXC_0),
> .PHYEMAC0RXD ({RGMII_RXD_FALLING_0,
> RGMII_RXD_RISING_0}),
> .PHYEMAC0RXDV (RGMII_RX_CTL_RISING_0),
> .PHYEMAC0RXER (RGMII_RX_CTL_FALLING_0),
> .PHYEMAC0MIITXCLK (),
> .EMAC0PHYTXCLK (),
> .EMAC0PHYTXD ({RGMII_TXD_FALLING_0,
> RGMII_TXD_RISING_0}),
> .EMAC0PHYTXEN (RGMII_TX_CTL_RISING_0),
> .EMAC0PHYTXER (RGMII_TX_CTL_FALLING_0),
> .PHYEMAC0COL (1'b0),
> .PHYEMAC0CRS (1'b0),
> ...
> );
>
> Interestingly receiving works in both cases. In my naive thinking I
> would believe that both snippets are semantically identical. So where
> did I make an error? Are there some optimizations which changed the
> behaviour?
>
> Thanks,
> Christian.
The two snippets are essentially equivalent. My first guess would be
that
your project is not adequately constrained to meet timing requirements
of transmit. It is possible that you get a better fit by renaming the
two
4-bit pieces into an 8-bit bus, due to the mapping feature of "register
ordering", which tries to find bus structures by name and place them
in adjacent logic elements.
HTH,
Gabor
Article: 113383paulcullen@purewebsites.co.uk wrote: > What is the sign-and-magnitude of the following 4's complement > number? (Leave answer in base 4). > > The number: 33333210 (base 4) > > Hi, Ive been asked the following question and although slightly > familary with compure match and storage, i can't figure this. I gather > it needs converting > > > Thanks a lot in advance > > Paul > May I suggest looking at Isreal Koren's "Computer Arithmetic Algorithms". He has a pretty good treatment of number systems in there.Article: 113384
paulcullen@purewebsites.co.uk wrote: > What is the sign-and-magnitude of the following 4's complement > number? (Leave answer in base 4). > > The number: 33333210 (base 4) > > Hi, Ive been asked the following question and although slightly > familary with compure match and storage, i can't figure this. I gather > it needs converting > > > Thanks a lot in advance > > Paul Well, sometimes we help with homework, sometimes we don't - I'll give a little help. As it's better if you do the conversion yourself, consider that a base 4 number is in fact two bits in base 2 (if you want to use a calculator). The sign of the number is obvious from inspection. If it's positive, then the answer is the value stated. if it's negative, then simply subtract the above number from 400000000 (base 4) or alternatively, subtract the number from 33333333 and add 1. If you have some reason other than homework to ask, do tell :) Cheers PeteSArticle: 113385
Hello, I'm wanting to perform some image processing on a development board available at my university, Xilinx University Program Virtex-2 pro board (Digilent). http://www.xilinx.com/univ/xupv2p.html I'm using a couple of camera link based cameras, currently using a frame-grabber and PC to perform the processing. My question is has anyone worked with camera link (or channel link) signals on this type of board? Are there any add-on modules that will make life easier, or will it be a case of building my own interface on the board taking signals directly from the camera link connectors? ANY help i'd be very grateful. Kind regards Marc.Article: 113386
Hi, I'm looking for some information on the proprietary ISP interface used by Lattice (specifically in the ispGDS22 device) I've managed to find a Lattice document describing the function of the SDI,SDO,MODE + SCLK pins and the devices internal state machine, but nothing on specifically how to get the fuse map /JEDEC file into the device 'in-situ'. I've searched the Lattice website, but they don't seem to give out this information readily. Can anyone direct me to a suitable resource? Many thanks DavidArticle: 113387
On 2006-12-09, burn.sir@gmail.com <burn.sir@gmail.com> wrote: > I usually get this kind of behavior when i forget to synchronize > external signals before reading them. google for "Peter Alfke" and > "Metastability" for more info. Just a clarification, forgetting to synchronize external signals is more likely to cause race conditions in your design than metastability problems. I'd suggest "Peter Alfke" and "Spectre of metastability" as search terms instead. /AndreasArticle: 113388
here's a nice picture of the camera link bit serialization (pg 8) http://www.fast-vision.com/Downloads/bgawc4510/DS90CR288A.pdf You will have to see if there are lvds deserilizers on the xup board ... Probably Xilinx will have some answers on their website. Look up the device data sheet and the voltage i/o standards supported by the device. The schematic port names may also provide useful hints as to available ports and functionality. If there are no ports specifically dedicated as lvds deserializers but you do have lvds ports, you can write your own deserializer block (although it has to meet timing at 7x the camera clock) send the input clock into a DCM or PLL and run the output at 7x, then use this clock to run a shift register to shift in the 7x serialized data For camera link there are 4 lvds pairs, for a total of 28 bits of serialized data, so it you can write this easily as 4 7 bit registers, that shift in a new data bit on each 7x clock. You may have to play with the phase shift of the 7x clock with respect to the 1x camera clock, in order to sample each bit in the eye of the data... just pay attention to the line valid and frame valid bits, if you are getting errors recovering these move the 7x clock phase shift around until you get them to look correct, then the rest of the pixel data bits will also be sampled at the right time as well... --hope this helps MJ Pearson wrote: > Hello, > > I'm wanting to perform some image processing on a development board > available at my university, Xilinx University Program Virtex-2 pro board > (Digilent). > > http://www.xilinx.com/univ/xupv2p.html > > I'm using a couple of camera link based cameras, currently using a > frame-grabber and PC to perform the processing. > > My question is has anyone worked with camera link (or channel link) > signals on this type of board? Are there any add-on modules that will make > life easier, or will it be a case of building my own interface on the board > taking signals directly from the camera link connectors? > > ANY help i'd be very grateful. > > Kind regards > > Marc.Article: 113389
John wrote: > Anyone have tips on having the Virtex 4 generate cleaner signals? I have 8 data lines coming out from the header IOs. They are supposed to be 3.3V but the noise amplitude swing is rather big, sometimes the high signal dips all the way to 2.1V. > > I have slew rates set to fast, drive is 12. What can I do in the FPGA to improve signal quality? It sounds like you have reflections on your 8 data lines, which means that your lines are not terminated properly. Try setting the slew rate to SLOW and the drive to the lowest current level you can get away with. This will lengthen the rise and fall times of the signals, which should help, but might not "fix" your problem. Read up on transmission lines and termination, and Signal Integrity (SI). I think there are APP notes on SI on Xilinx's web site, but I'm not sure. HTH -Dave PollumArticle: 113390
David <dpmontminy@gmail.com> wrote in message 1165887810.492582.147580@n67g2000cwd.googlegroups.com... > I hope this helps, Thanks a lot David! AntonioArticle: 113391
Joseph Samson wrote: > Chao wrote: >> Hi, everyone >> I am designing a FPGA PCB board with one DDR2 dimm memory slot. As >> current project will only need single dimm slot, is that mean I don't >> need any termination resistor on the board? Since the DDR2 will have >> ODT(On Die Termination) technology. Even without ODT, it should not >> cause signal reflection problem since this is only one dimm slot. > > Remember, ODT is for the bidirectional signals only (data, strobe, > mask), not clock, address or command. Yes, These signal need special care. Generally, ODT is new tech for decreasing the number of termination resistors from the board and increase integrity performance. Based on the information provided from http://www.elpida.com/pdfs/E0593E10.pdf, I believe if there is no second DDR2/DDR RAM slot, the signal reflection won't happen at all. So, my thought is: if only one DDR2/DDR RAM slot, no matter ODT or not, termination resistors are not necessary, and they might even be harmful since extra path will increase more trouble. As far as I know, there is no where mention this situation. Since all the design I saw today come with two memory slots. > >> There is no standby hi-Z on the end of transmission line. So there is >> no necessary to put termination resistors on the end? Normal ref >> design have two DDR2 Dimm Slots, I believe single slot is different. >> Can anyone tell this idea is correct or more things need to be concern? > > Micron has lots of application notes here: > > http://www.micron.com/support/designsupport/documents/technotes > > including the very interesting TN4720 which has recommendations on > termination and trace length matching. > > --- > Joe Samson > Pixel Velocity Good reference, thanks for all you guys information. ChaoArticle: 113392
David schrieb: > Hi, > > I'm looking for some information on the proprietary ISP interface used > by Lattice (specifically in the ispGDS22 device) > > I've managed to find a Lattice document describing the function of the > SDI,SDO,MODE + SCLK pins and the devices internal state machine, but > nothing on specifically how to get the fuse map /JEDEC file into the > device 'in-situ'. I've searched the Lattice website, but they don't > seem to give out this information readily. > > Can anyone direct me to a suitable resource? > > Many thanks > > David lattice ISP sw source code used to be available but I think it no longer is :(Article: 113393
You might also try changing your IO Standard to LVDCI (Low voltage Digitally Controlled Impedance). I've used this in the past to clean up my signals. Note, using this standard requires external reference resistors be connected to enable DCI. You'll have to check the board schematics usualy IO_,,,_VRP and IO_,,,_VRN on each FGPA bank.Article: 113394
Antti wrote: > David schrieb: > >> Hi, >> >> I'm looking for some information on the proprietary ISP interface used >> by Lattice (specifically in the ispGDS22 device) >> >> I've managed to find a Lattice document describing the function of the >> SDI,SDO,MODE + SCLK pins and the devices internal state machine, but >> nothing on specifically how to get the fuse map /JEDEC file into the >> device 'in-situ'. I've searched the Lattice website, but they don't >> seem to give out this information readily. >> >> Can anyone direct me to a suitable resource? >> >> Many thanks >> >> David > > lattice ISP sw source code used to be available > but I think it no longer is :( > Hmmm... that may make me think twice about using Lattice devices; ISP is a key requirement. Cheers PeteSArticle: 113395
PeteS schrieb: > Antti wrote: > > David schrieb: > > > >> Hi, > >> > >> I'm looking for some information on the proprietary ISP interface used > >> by Lattice (specifically in the ispGDS22 device) > >> > >> I've managed to find a Lattice document describing the function of the > >> SDI,SDO,MODE + SCLK pins and the devices internal state machine, but > >> nothing on specifically how to get the fuse map /JEDEC file into the > >> device 'in-situ'. I've searched the Lattice website, but they don't > >> seem to give out this information readily. > >> > >> Can anyone direct me to a suitable resource? > >> > >> Many thanks > >> > >> David > > > > lattice ISP sw source code used to be available > > but I think it no longer is :( > > > > Hmmm... that may make me think twice about using Lattice devices; ISP is > a key requirement. > > Cheers > > PeteS there should be no problems with recent devices, I was referring to ISP source code for devices like ispGAL, etc.. I had it once, but I think this was still the "floppy disk era" so not sure if I still have to code for new devices the embedded programming is obtainable AnttiArticle: 113396
Antti wrote: > PeteS schrieb: > >> Antti wrote: >>> David schrieb: >>> >>>> Hi, >>>> >>>> I'm looking for some information on the proprietary ISP interface used >>>> by Lattice (specifically in the ispGDS22 device) >>>> >>>> I've managed to find a Lattice document describing the function of the >>>> SDI,SDO,MODE + SCLK pins and the devices internal state machine, but >>>> nothing on specifically how to get the fuse map /JEDEC file into the >>>> device 'in-situ'. I've searched the Lattice website, but they don't >>>> seem to give out this information readily. >>>> >>>> Can anyone direct me to a suitable resource? >>>> >>>> Many thanks >>>> >>>> David >>> lattice ISP sw source code used to be available >>> but I think it no longer is :( >>> >> Hmmm... that may make me think twice about using Lattice devices; ISP is >> a key requirement. >> >> Cheers >> >> PeteS > > there should be no problems with recent devices, > I was referring to ISP source code for devices like ispGAL, etc.. > I had it once, but I think this was still the "floppy disk era" so > not sure if I still have to code > > for new devices the embedded programming is obtainable > > Antti > Thanks for that clarification, Antti :) Cheers PeteSArticle: 113397
John Adair wrote: > Hillls actually. What are Hillls ? Shorter mountains, or taller hills ? :) -jgArticle: 113398
DCI allows you to set the output impedance to a specific value. If that equals the impedance of the interconnect (let's hope the interconnect has a defined impedance and is not just a rats' nest of wires). The rising or falling edge at the FPGA output will then have half amplitude (voltage division between driver and load) and will travel down the wire to the unterminated (!) load, where it gets reflected and travels back to the source, where it gets absorbed. This is the nicest way to handle unidirectional interconnects, single-source, single-destination. Peter Alfke Xilinx On Dec 12, 10:28 am, "JuanC" <juan.javier.cuel...@gmail.com> wrote: > You might also try changing your IO Standard to LVDCI (Low voltage > Digitally Controlled Impedance). I've used this in the past to clean up > my signals. Note, using this standard requires external reference > resistors be connected to enable DCI. You'll have to check the board > schematics usualy IO_,,,_VRP and IO_,,,_VRN on each FGPA bank.Article: 113399
Definately on the smaller end. Here is a picture http://www.geograph.org.uk/photo/270797 I found. Jim Granville wrote: > John Adair wrote: > > > Hillls actually. > > What are Hillls ? > Shorter mountains, or taller hills ? :) > > -jg
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