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
John_H wrote: > > Brian, I always appreciate a well-considered discussion and hope to look > at the T-coil references. Beyond these references I don't know that the > rest of the discussion does much more than stir the bees nest though I > do also appreciate the perspective from the curve tracer. > If you really believe "Cin doesn't matter", and that all drivers are perfectly balanced with ideal back terminations, then best of luck with your high speed designs; somehow, I suspect you are more pragmatic. > > Austin, I'm sure you want to retort. Could you let this one go by > without a response? It's feeling old. > What I find old is vendor employees continuing to make known false or misleading claims like "(We) meet all specs and standards", "Cin doesn't matter", and "but it's really Cin/2". If I occasionally point out the real-world issues on a thread where the subject comes up, it's only after I've counted slowly backwards from 200 by two's and deleted most of my original response. BrianArticle: 120026
On May 30, 1:36 pm, austin <aus...@xilinx.com> wrote: > Heck, we (APD FPGA Lab) have purchased Digilent boards for use here at > Xilinx in the past! A lot cheaper than fiddling with making something > ourselves. > > Once a board exists from a vendor, no reason to re-invent the wheel. Glad to hear a logic company is open to the logical solution. My comment though was more that for a relatively interesting and extremely inexpensive board, Nexys seems to have a very small user base. Search this newsgroup on it, and there's only a very few threads - wheras there are many mentions of the S3 kit, S3E, etc boards. I was speculating that perhaps the difference there was that those are Digilent boards which Xilinx promotes, wheras Nexys is Digilent operating only on its own. The practical impact of this is that while a user can benefit a lot from others work on the more popular boards - downloaded project skeletons, solutions, and general advice, for the less popular boards they are on their own... or nominated to blaze the trail.Article: 120027
Hi,
I want to test what kind of delay is introduced by having an input go
through 1000 LUT1 primitive in a Spartan3E FPGA. I am using ISE 9.1 to
synthesize this but during map, it seems that it is optimizing the
LUTs out although these were instantiated as primitives. Is there any
way to force ISE to keep these. The design is as follows:
[CODE]
library IEEE;
use IEEE.STD_LOGIC_1164.all;
-- Synthesis TRANSLATE_OFF
library SPARTAN3E;
use SPARTAN3E.VPKG.all;
use SPARTAN3E.VCOMPONENTS.all;
-- Synthesis TRANSLATE_ON
entity delay_luts is
port(
input : in STD_LOGIC;
output : out STD_LOGIC
);
end delay_luts;
--}} End of automatically maintained section
architecture delay_luts of delay_luts is
CONSTANT number_of_delay : INTEGER := 1000;
component LUT1 is
generic(INIT : bit_vector := X"0");
port(
O : out std_ulogic;
I0 : in std_ulogic);
end component;
signal internal_signal : STD_LOGIC_VECTOR(number_of_delay-1 downto 0);
begin
delay_element_first : LUT1
generic map(INIT => X"2")
port map(
O => internal_signal(0),
I0 => input
);
-- enter your statements here --
delay : for N in 0 to number_of_delay-2 GENERATE
delay_element_middle : LUT1
generic map(INIT => X"2")
port map(
O => internal_signal(N+1),
I0 => internal_signal(N)
);
end GENERATE delay;
delay_element_last : LUT1
generic map(INIT => X"2")
port map(
O => output,
I0 => internal_signal(number_of_delay-1)
);
end delay_luts;
[/CODE]
Thanks,
Amish
Article: 120028
On May 30, 8:14 pm, Pablo Bleyer Kocik <pabloble...@hotmail.com>
wrote:
> On May 30, 4:14 pm, "dscol...@rcn.com" <dscol...@rcn.com> wrote:
>
> > Pablo,
>
> > I was also wondering if you fixed the issues with the assembler that I
> > wrote to you about last June?
>
> > >From email sent to you.
>
> Hello Dave.
>
> Yes, these issues have been fixed. The assembler now accepts bounded
> '()' tokens; just as a visual convenience since they are converted to
> regular arguments. The default format is now hexadecimal. If a name is
> not found in the environment, and if that word is a valid hex number,
> it gets converted to the latter. It's a shame the kcpsm assembler
> treats numbers these way, it is not the default format of most
> assemblers, and usually numbers in a different radix are decorated in
> some way to avoid confusion or a clash with valid labels. KCAsm
> supports binary (%) octal (@), decimal (&), and hexadecimal ($)
> modifiers.
>
> KCAsm still accepts names only in valid C format - the identifiers
> can't start with a number or symbol different to the underscore (_).
>
> Please tell me if you find other issues.
>
> Best regards.
>
> --
> PabloBleyerKocik /"But what... is it good for?"
> pablo / -- 1968 Engineer at IBM's Advanced Computing
> @bleyer.org / Systems Division, commenting on the microchip
Pablo,
Thanks for the fixes. However, I Just found another "bug" more of a
compatibility issue. KCPSM allows the following renaming of registers
as follows:
first namereg
namereg s4, clkcnt ; temp register
:
:
later renamed S4. however, KCPSM requires you use the name you renamed
S4 to previously.
namereg clkcnt, DIFF0 ;
Here is the output of KCasm
I don't know if this one will be an easy one the fix.
C:\clcfpga2\PACOBL~1.2\test>asmkcpsm isp
C:\clcfpga2\PACOBL~1.2\test>java -Dkcpsm=3 -Dbram=18 -Dmodule=isp -jar
c:/clcfpga2/pacoblaze-
2.2/KCAsm.jar isp.psm isp.rmh
Exception in thread "main" java.lang.IllegalArgumentException: Bad
register declaration: name
reg(clkcnt,DIFF0) at line 1358
at Assembler.parse(Assembler.java:155)
at Assembler3.<init>(Assembler3.java:55)
at KCAsm.main(KCAsm.java:48)
C:\clcfpga2\PACOBL~1.2\test>
Best regards
Dave
Article: 120029Since it looks like you're instantiating the LUTs, two things: 1) Use the LOCK_PINS=ALL constraint to force the mapper to keep the LUTs; check the constraints guide for the current syntax. 2) To avoid pulse-width compression (different delays for opposite transitions) invert the signal at each LUT so the end result is normal but every-other LUT is inverted. axr0284 wrote: > Hi, > I want to test what kind of delay is introduced by having an input go > through 1000 LUT1 primitive in a Spartan3E FPGA. I am using ISE 9.1 to > synthesize this but during map, it seems that it is optimizing the > LUTs out although these were instantiated as primitives. Is there any > way to force ISE to keep these. The design is as follows: > [CODE] > library IEEE; > use IEEE.STD_LOGIC_1164.all; > > -- Synthesis TRANSLATE_OFF > library SPARTAN3E; > use SPARTAN3E.VPKG.all; > use SPARTAN3E.VCOMPONENTS.all; > -- Synthesis TRANSLATE_ON > > entity delay_luts is > port( > input : in STD_LOGIC; > output : out STD_LOGIC > ); > end delay_luts; > > --}} End of automatically maintained section > > architecture delay_luts of delay_luts is > > CONSTANT number_of_delay : INTEGER := 1000; > component LUT1 is > generic(INIT : bit_vector := X"0"); > > port( > O : out std_ulogic; > I0 : in std_ulogic); > end component; > > signal internal_signal : STD_LOGIC_VECTOR(number_of_delay-1 downto 0); > begin > delay_element_first : LUT1 > generic map(INIT => X"2") > port map( > O => internal_signal(0), > I0 => input > ); > > -- enter your statements here -- > delay : for N in 0 to number_of_delay-2 GENERATE > delay_element_middle : LUT1 > generic map(INIT => X"2") > port map( > O => internal_signal(N+1), > I0 => internal_signal(N) > ); > end GENERATE delay; > > delay_element_last : LUT1 > generic map(INIT => X"2") > port map( > O => output, > I0 => internal_signal(number_of_delay-1) > ); > end delay_luts; > [/CODE] > Thanks, > AmishArticle: 120030
cs_posting@hotmail.com wrote: : My comment though was more that for a relatively interesting and : extremely inexpensive board, Nexys seems to have a very small user : base. Search this newsgroup on it, and there's only a very few : threads - wheras there are many mentions of the S3 kit, S3E, etc : boards. I was speculating that perhaps the difference there was that : those are Digilent boards which Xilinx promotes, wheras Nexys is : Digilent operating only on its own. The Nexys has to be about my favourite board - compact, dirt cheap (even with the S3-1000 part), the same pinout FX2 header as their other boards (with 6 extra IOs even) and the key point for me is the Cypres EZ-USB device on the board has all the key pins conencted to produce your own USB interface using the FPGA and the Cypress part. Other boards from Digilent are now using the Xilinx USB cable firmware, redacting the schematics and (presumably) not connecting the main data ports, which is a shame as having a decent on-board USB2 interface is a major time/hastle saver for me. (Thinly disguised whinge about their S3E starter board... :-) Cheers cdsArticle: 120031
Hi, I'm trying to build and test a simple project for Spartan 3E Starter Kit rev D (S3ESK) board using Xilinx EDK tool and using the BSB wizard. The project is the auto generated peripherals test. These peripherals are simply a 8 LEDs, 4 DIP Switches, 4 Push Buttons and a UART lite. The problem is that when I use EDK 8.2 the project compile and load to the FPGA without any error but it simply does nothing. But, if I use EDK 8.1 then the test does what it suppose to do (print on the uart, read switches state and flash a leds). I've tried it out on 2 different PC's. I even try to use the BSB but with the "I would like to create a system from a custom board" option, but it didn't help. Is there any known bug related to edk8.2 and S3ESK or I should do some special steps to get it work with EDK 8.2????Article: 120032
On May 31, 9:16 am, christopher.saun...@durham.ac.uk (c d saunter) wrote: > The Nexys has to be about my favourite board - compact, dirt cheap (even > with the S3-1000 part), the same pinout FX2 header as their other boards > (with 6 extra IOs even) and the key point for me is the Cypres EZ-USB > device on the board has all the key pins conencted to produce your own > USB interface using the FPGA and the Cypress part. Yes... in theory. But have you gotten it working yet? It's not a problem with the board, it's just that getting the fx2 all ready to go is a non-trivial exercise, and most existing open source projects for it do some wierd things, require oddbal build environments rather than simply the SDCC complier on its own, want to do the host side in python, etc... What happened to good old C and Makefiles? I did manage to get the FPGA programmed through the USB using some modified open source programming tools, but then had to put it back on the shelf to work on other things before I could get the data flowing. Would be great if there were a simple, open, framework for doing USB data communication (firmware stub + fpga code stub + libusb host code)Article: 120033
John, No, I am tied of the ranting. Fact is, it works. Also, there were some customers that had really bad experiences trying to make their boards work. Far be it from me to suggest that these folks did something wrong, but I have to wonder why other customers have this working. All I can say is that we have demo boards, with network interfaces, running at DDR rates of 800 Mbs, and on V5, at 1 Gbs. So, it is more than a data sheet claim, it is working, proven across PVT, with HDL code; solutions. AustinArticle: 120034
Brian Davis wrote: > John_H wrote: >> Brian, I always appreciate a well-considered discussion and hope to look >> at the T-coil references. Beyond these references I don't know that the >> rest of the discussion does much more than stir the bees nest though I >> do also appreciate the perspective from the curve tracer. >> > If you really believe "Cin doesn't matter", and that all drivers are > perfectly balanced with ideal back terminations, then best of luck > with > your high speed designs; somehow, I suspect you are more pragmatic. > >> Austin, I'm sure you want to retort. Could you let this one go by >> without a response? It's feeling old. >> > What I find old is vendor employees continuing to make known > false or misleading claims like "(We) meet all specs and standards", > "Cin doesn't matter", and "but it's really Cin/2". > > If I occasionally point out the real-world issues on a thread where > the subject comes up, it's only after I've counted slowly backwards > from 200 by two's and deleted most of my original response. > > Brian Cin matters but - in a properly designed system - it doesn't matter so much. If the impedances in the system - source, transmission line, receiver - are crap, then the C will have a huge impact. Since the transmitters will tend to have high C as well in Xilinx transmitters, reflections should be expected. One thing you appear to rely on from previous posts is probing of the signal at a point external to the receiver silicon, the only place practical to probe. This will always result in a signal that's worse than the actual received signal when high Cs (or other impedance mismatches) are involved. Since these are digital systems, *some* reflections are acceptable. Having a signal without extremely well defined highs and lows are typically acceptable. The impact on the time-domain is where the interference will often be noted the most and transmission systems with much better analog performance (including the C and R termination values) are required to maintain a low phase noise. It really is C/2 for those who are thinking 100 ohm impedance. It really is C for those who are thinking 50 ohm impedance. Where are peoples' minds normally on the impedance for LVDS? There are no lies here. I've been impressed with an engineer's approach within my own company to try to reduce common-mode artifacts and EMC issues by filtering from the midpoint of the differential termination. It becomes less obvious why a well-matched C value is so critical when his termination scheme is scrutinized. I was impressed. Your real-world issues are flavored by the way you observe your system. The SI results will often provide much better response than your practical observations. That appears to be a thorn in Austin's side in the same way his C/2 "claims" are a thorn in yours. I have always found your responses to be well considered and sincerely appreciate your self-editing: a rare talent on a forum like this. While you may hate the impairments induced by the LVDS transceivers that are hampered by a design that supports multiple I/O standards, it impresses the hell out of me just how open the data eyes are in the chip. Take a sample of your high-speed data with a carry-chain as a delay element and accumulate. You'll see how good or bad the time-domain is. You can futz with the common-mode, add an offset to the differential, or reduce the transmitter swing to see when and how this eye starts to break down. I love that a 600 Mbit link in the "cheap" S3E devices hampered not by one but by TWO DCMs can result in an eye that's still half open; I could blame just about all of that mess on the DCMs, not the LVDS transceivers. - John_HArticle: 120035
cs_posting@hotmail.com wrote: : On May 31, 9:16 am, christopher.saun...@durham.ac.uk (c d saunter) : wrote: : > The Nexys has to be about my favourite board - compact, dirt cheap (even : > with the S3-1000 part), the same pinout FX2 header as their other boards : > (with 6 extra IOs even) and the key point for me is the Cypres EZ-USB : > device on the board has all the key pins conencted to produce your own : > USB interface using the FPGA and the Cypress part. : Yes... in theory. But have you gotten it working yet? Yup. Mind you I'm only using it for a high speed data interface and not trying to get the JTAG working - from my viewpoint the board has a perfectly good JTAG header on it and Digilent do cheap and functional USB2 JTAG cables... : It's not a problem with the board, it's just that getting the fx2 all : ready to go is a non-trivial exercise, and most existing open source : projects for it do some wierd things, require oddbal build : environments rather than simply the SDCC complier on its own, want to : do the host side in python, etc... What happened to good old C and : Makefiles? I looked at using open source code and SDCC, but couldn't face it. Why make life complicated... Cypress provide some decent example projects for use with the Keil tools, and a download of a limited version of uVision / C51 etc. with commercial and code size restrictions. Using those tools you can get things running quite rapidly by modifying the example projects. The EZ-USB device isn't the simplest thing in the world though. I'd not be comfortable distributing any code built with SDCC as everyone seems to use the fx2regs.h file written and (C) by Keil. (Nothing to stop someone producing their own from the monumental tech. ref manual) : I did manage to get the FPGA programmed through the USB using some : modified open source programming tools, but then had to put it back on : the shelf to work on other things before I could get the data : flowing. Would be great if there were a simple, open, framework for : doing USB data communication (firmware stub + fpga code stub + libusb : host code) Again I used their CyUsb windows driver as there was then example code to work from. Even if you want to end up with a FOSS stack it's worth starting with the Keil tools and CyUsb / MSVC as otherwise there are to many unknowns and pitfalls. --- cdsArticle: 120036
Thanks a lot Ken! > Depending what version of Kubuntu you're running, you may have other > troubles. For example, if you get errors referencing GLIBC you need > to set the environment variable LD_ASSUME_KERNEL=2.4.7 (this is not a > problem in recent releases of ISE/EDK). I am running Kubuntu 7.04, 32-bit version and the 9.1 version of the Xilinx tools. I don't recall seeing this error... > Getting a download cable to work is also a treat. I recommend ignoring > the Xilinx drivers and use the userspace driver from: > > http://www.rmdir.de/~michael/xilinx/ That's really a great advice! I was just in the middle of the process of trying to install Xilinx drivers :) Hopefully I haven't broken anything yet by half-working scripts :) > I have it working for impact, chipscope analyzer, and XMD, at least > in all modes I actually use. I can elaborate further all the fun I > had getting it to work on a 64-bit system, if that's something you'll > need (post here but CC my email to be sure I see it; I don't check > every day). It's interesting. I was told in the past by Xilinx that EDK wasn't working on 64-bit systems... Have they fixed it in 9.1 or have you found a workaround? > In any case, it works great on my Linux boxen which is a relief since > EDK does not get along with my laptop at all (multiple applications > built on top of Cygwin are not playing nice at all). > > Good luck, and drop me a note if you need more help. Thanks again, /MikhailArticle: 120037
"austin" <austin@xilinx.com> wrote in message
news:f3khoi$siu13@cnn.xilinx.com...
> Hans,
>
> Like the joke here about attending UC Berkeley in the late 1960's
> ("summer of love"): "if you can remember it, you weren't here."
>
> By the way, I was (for a short time) a counselor for the BCIPD (Berkeley
> Committee for Information on Psychedelic Drugs): one of the great
> crimes, and wastes of good minds was the abuse of both legal, and
> illegal drugs by the youth of that time. These poor souls are now
> cluttering up the mental hospitals, or wandering the streets, and have
> become a burden to society.
>
> Not that I have any solution to this (continuing) problem, but I at
> least had the chance to talk to people and try to convince them not to
> turn their brains into soup.
>
> I am also fortunate I survived.
>
> Austin
Hi Austin,
I wasn't serious, most people associate Amsterdam with drugs which is
obviously a distorted view. To be honest, I was actually quite a boring
non-smoking, non-drinking, non-drug taking nerd that spend most of his time
studying and playing with his AppleII+............. oh well, at least I
ended up with a great job :-)
Drugs (mainly alcohol here in the UK) it is indeed a serious problem but I
am afraid that even if there was a solution nobody would take notice of it,
Regards,
Hans.
www.ht-lab.com
Article: 120038On May 31, 10:07 am, John_H <newsgr...@johnhandwork.com> wrote: > Since it looks like you're instantiating the LUTs, two things: > 1) Use the LOCK_PINS=ALL constraint to force the mapper to keep the > LUTs; check the constraints guide for the current syntax. > 2) To avoid pulse-width compression (different delays for opposite > transitions) invert the signal at each LUT so the end result is normal > but every-other LUT is inverted. Thanks for the answer. I used the following to force ISE to keep the LUTs: attribute keep : string; attribute keep of internal_signal: signal is "true"; I am this "pulse width compression" and I am wondering why that occurs. Is it possible to give me a more in depth explanation or point me to some website that has the info. Thanks. AmishArticle: 120039
On 31 mayo, 16:28, thomas....@gmail.com wrote: > Hi, > > I'm trying to build and test a simple project for Spartan 3E Starter > Kit rev D (S3ESK) board using Xilinx EDK tool and using the BSB > wizard. The project is the auto generated peripherals test. These > peripherals are simply a 8 LEDs, 4 DIP Switches, 4 Push Buttons and a > UART lite. The problem is that when I use EDK 8.2 the project compile > and load to the FPGA without any error but it simply does nothing. > But, if I use EDK 8.1 then the test does what it suppose to do (print > on the uart, read switches state and flash a leds). I've tried it out > on 2 different PC's. I even try to use the BSB but with the "I would > like to create a system from a custom board" option, but it didn't > help. > > Is there any known bug related to edk8.2 and S3ESK or I should do some > special steps to get it work with EDK 8.2???? Use ISE flow to implement this. I don't know why but I had the same problem in virtexIIPro. Another option is to look the bitgen.ut.Article: 120040
axr0284 wrote: > On May 31, 10:07 am, John_H <newsgr...@johnhandwork.com> wrote: >> Since it looks like you're instantiating the LUTs, two things: >> 1) Use the LOCK_PINS=ALL constraint to force the mapper to keep the >> LUTs; check the constraints guide for the current syntax. >> 2) To avoid pulse-width compression (different delays for opposite >> transitions) invert the signal at each LUT so the end result is normal >> but every-other LUT is inverted. > > > Thanks for the answer. I used the following to force ISE to keep the > LUTs: > attribute keep : string; > attribute keep of internal_signal: signal is "true"; > > I am this "pulse width compression" and I am wondering why that > occurs. Is it possible to give me a more in depth explanation or point > me to some website that has the info. Thanks. > Amish I don't have references, only experience. The Tphl and Tplh numbers for a digital element (Time of Propagation for High-to-Low or Low-to-High transitions) are slightly different given the nature of asymmetric slew rates, DC logic levels, and switch points. It's only noticeable in high-speed logic or when many elements are chained together. In your case, a 4 ns pulse traveling through your 1k LUT chain will probably either come out as no pulse or as 10s of ns. If you search for tphl and tplh, you might find hits on data sheets that specify the two values or a difference between the two.Article: 120041
Among the many thousands of tests performed on every chip before it leaves the factory, are propagation delay tests of highly concatenated LUTs. So, you are in good company... Peter Alfke, Xilinx Applications On May 31, 8:50 am, John_H <newsgr...@johnhandwork.com> wrote: > axr0284 wrote: > > On May 31, 10:07 am, John_H <newsgr...@johnhandwork.com> wrote: > >> Since it looks like you're instantiating the LUTs, two things: > >> 1) Use the LOCK_PINS=ALL constraint to force the mapper to keep the > >> LUTs; check the constraints guide for the current syntax. > >> 2) To avoid pulse-width compression (different delays for opposite > >> transitions) invert the signal at each LUT so the end result is normal > >> but every-other LUT is inverted. > > > Thanks for the answer. I used the following to force ISE to keep the > > LUTs: > > attribute keep : string; > > attribute keep of internal_signal: signal is "true"; > > > I am this "pulse width compression" and I am wondering why that > > occurs. Is it possible to give me a more in depth explanation or point > > me to some website that has the info. Thanks. > > Amish > > I don't have references, only experience. The Tphl and Tplh numbers for > a digital element (Time of Propagation for High-to-Low or Low-to-High > transitions) are slightly different given the nature of asymmetric slew > rates, DC logic levels, and switch points. It's only noticeable in > high-speed logic or when many elements are chained together. In your > case, a 4 ns pulse traveling through your 1k LUT chain will probably > either come out as no pulse or as 10s of ns. > > If you search for tphl and tplh, you might find hits on data sheets that > specify the two values or a difference between the two.Article: 120042
Pablo wrote: > Hi, I am very interesting in how could I use ISE to create a PowerPC > model. <snip> > But I cannot see the complete vhdl code. For example I cannot see the > code from the dcm_module, the code from the util_vector_module, etc. > > I know that quite a lot designers use this ISE Flow, but how can they > see the complete project in vhdl. The VHDL for the EDK IP is not available. You can go to $XILINX_EDK/hw/XilinxProcessorIPLib/pcores to see the IP that can be instantiated from EDK. There are VHDL wrappers that instantiate black boxes. In some cases (plb_ethernet) there is encrypted VHDL. --- Joe Samson Pixel VelocityArticle: 120043
On 31 mayo, 18:31, Joseph Samson <jsam...@the-company-name.com> wrote: > Pablo wrote: > > Hi, I am very interesting in how could I use ISE to create a PowerPC > > model. > > <snip> > > > But I cannot see the complete vhdl code. For example I cannot see the > > code from the dcm_module, the code from the util_vector_module, etc. > > > I know that quite a lot designers use this ISE Flow, but how can they > > see the complete project in vhdl. > > The VHDL for the EDK IP is not available. You can go to > $XILINX_EDK/hw/XilinxProcessorIPLib/pcores to see the IP that can be > instantiated from EDK. There are VHDL wrappers that instantiate black > boxes. In some cases (plb_ethernet) there is encrypted VHDL. > > --- > Joe Samson > Pixel Velocity So the only thing I could edit is the system_stub.vhd and the system.vhd with inputs and outputs. Cores couldn't be edited. Correct me?Article: 120044
Hans,
I too, was a boring, slide rule toting Engineering "nerd."
As I walked across campus, the Alameda County Sheriffs ("Blue Meanies)
would be drinking their coffee with their dough nuts, remarking "good
day for a riot, isn't it?"
Go read "People's Park" on Wikipedia for a fairly well written
historical account of those days.
Austin
Article: 120045On May 29, 12:17 pm, "CTU FEE Jan Krakora" <krak...@control.felk.cvut.cz> wrote: > To specify the problem, I thought the "Fatal: (vsim-3348)" one. Sorry Jan hi Jan, I still have the problem. I am using linux (debian) and the people from xilinx told me today, that debian it is not supported, Only Red Hat Enterprise 3. But this is very weird because I am using it, and it works normally, the only think that is not working is the simulation in modelsim. I told one of my supervisors and he told me that he thinks that our problem is not a problem of operating system or EDK, he thinks that it is a problem of Modelsim. But I dont know how to solve it. I will continue trying to solve the problem, if you get a solution, please let me knowArticle: 120046
Austin wrote: > > No, I am tied of the ranting. > And I am tired of your marketing misdirections. > > Also, there were some customers that had really bad experiences trying > to make their boards work. > > Far be it from me to suggest that these folks did something wrong, > but I have to wonder why other customers have this working. > My boards work great, because I know when and how to be cautious when driving FPGA inputs from fast logic. When's the last time YOU actually designed a PCB? The boards I've had problems with have been various Xilinx sanctioned "high speed" boards, with terminators hanging off big stubs, or similar mistakes [1]. > > All I can say is that we have demo boards, with network interfaces, > running at DDR rates of 800 Mbs, and on V5, at 1 Gbs. So, it is more > than a data sheet claim, it is working, proven across PVT, with HDL > code; solutions. > But where are your simulations and real-world test data [2] ? Take a look at XAPP774 and the associated board schematics for TI's ADS5273 EVB combo <sbau091.pdf> and <sbau093a.pdf> Where are the IBIS sims or real-world plots of input signal timing and margin when driving the FPGA? As I pointed out last spring, driving 10 pF Cin from an ADS5273 without back termination is a recipe for disaster [3]. And if you ever have the technical integrity to post a link to your 'works fine' IBIS simulation, I'd be happy to explain the mistakes you made when you penned these nasty remarks [4]: > > I don't know about anyone else, but it works fine, and posts > like this of sims poorly done are not helpful to anyone. > > I am sorry I took your posting seriously enough to do a real > simulation and show that there is no problem (which I knew > already from the customers that are using our parts successfully). > Brian [1] Big stubs on ML450 HyperTransport interface http://groups.google.com/group/comp.arch.fpga/msg/3654e1982a62ea81 [2] V4 thread looking for real-world measurements http://groups.google.com/group/comp.arch.fpga/msg/3dc2fc501b48d9b7 [3] updated ADS5273 simulation, IBIS vs. simple SPICE model http://groups.google.com/group/comp.arch.fpga/msg/5a8720eec942612e [4] Austin's attacks on my ADS5273 simulation http://groups.google.com/group/comp.arch.fpga/msg/33e48c977fa78001 http://groups.google.com/group/comp.arch.fpga/msg/6b33bab4a35999bfArticle: 120047
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cs_posting@hotmail.com wrote: > On May 31, 9:16 am, christopher.saun...@durham.ac.uk (c d saunter) > wrote: > >> The Nexys has to be about my favourite board - compact, dirt cheap (even >> with the S3-1000 part), the same pinout FX2 header as their other boards >> (with 6 extra IOs even) and the key point for me is the Cypres EZ-USB >> device on the board has all the key pins conencted to produce your own >> USB interface using the FPGA and the Cypress part. > > Yes... in theory. But have you gotten it working yet? > > It's not a problem with the board, it's just that getting the fx2 all > ready to go is a non-trivial exercise, and most existing open source > projects for it do some wierd things, require oddbal build > environments rather than simply the SDCC complier on its own, want to > do the host side in python, etc... What happened to good old C and > Makefiles? I have a demo board of my own that I put together that uses an EZ-USB-FX1/2. I've got it to talk USB using the default device and sdcc. The source code is really quite simple. I'll put a snapshot here: <ftp://ftp.icarus.com/pub/steve/mmc-20070531.tar.gz> It's also available via anonymous CVS if you are interested. The FX1/2 connection to the USE is common, so that part of the code should be directly applicable. - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGXwi0rPt1Sc2b3ikRAsBPAJ9oT1W+VXYKEZ02y3hH6R4dFQLmPgCfeHDl zg7gaVonzZJ2rB3lXBgoOQ4= =aSDu -----END PGP SIGNATURE-----Article: 120048
Peter Alfke <peter@xilinx.com> wrote: >Avnet picked Eindhoven as the preferred site in the Netherlands. They probably didn't want to drive too far themselves. Eindhoven is a bit of a technology hotspot due to Philips but it is in the east part of the country. Most people and companies are located in the west part of the country. Most major events are therefore either located in Amsterdam or Utrecht. >But the X-Fest seminar there was a month ago... >But the traditional European FPGA conference will be in Amsterdam in >August. Allright! -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 120049
On May 31, 10:04 am, "dscol...@rcn.com" <dscol...@rcn.com> wrote: > Pablo, > > Thanks for the fixes. However, I Just found another "bug" more of a > compatibility issue. KCPSM allows the following renaming of registers > as follows: > first namereg > namereg s4, clkcnt ; temp register > : > : > later renamed S4. however, KCPSM requires you use the name you renamed > S4 to previously. > > namereg clkcnt, DIFF0 ; > Thanks, Dave. I will look into that. Regards.
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