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
Hallo, has someone used that controller with LwIP and a Xilinx FPGA? Where I could find some examples? Many Thanks MarcoArticle: 97351
fpga_toys@yahoo.com schrieb: > Enter dynamic reconfigurability, and it's not even "firmware" any more > .... not hard locked in even a rom for many designs. More like a solid I would'nt connect the term "Firmware" to ROMs. For my understandig so far, Firmware is data in any storage medium (ROM/RAM/FLASH/Network) that is loaded into a "Execution memory", for a processor it will be RAM, for a FPGA it will be Config-RAM, or if yo like RAM for FSMs. How about this "definition"? Regards FalkArticle: 97352
Firmware is instruction-stream-based - more precisely: micro-instructions for programming the inner machine in a nested machine, where an instruction of the outer machine is executed by a sequence of micro-instruations by the inner machine. Programming FPGAs etc., however is NOT instruction-stream-based (i. e. NOT a procedural issue), and it should not be called "software" how some people do, because a software compiler generates an instruction schedule. Configuration code, however, is NOT an instruction schedule. It is a structural issue (but NOT procedural). The sources for compilation into configuration code should be called CONFIGWARE, and not software, nor firmware. A typical configware compilation process uses placement and routing, however, NOT instruction scheduling. FPGA code I call configware code - the output of configware compilation of design flow Best regards, Reiner http://fpl.org/RCeducation/Article: 97353
google for "microblaze uClinux" you'll se a good colection of demos for uClinux - all of them are copying the linux image into external SDRAM (or DDR sdram) and run from there. Aurash me_2003@walla.co.il wrote: > Hi all, > Does anyone knows of a complete reference design (preferably xilinx's) > describing a MB system that is running from external memory. > I'm trying to setup such a design and have some questions, I'll be > happy to get a well documented reference design to get me started.. > Thanks in advance , Mordehay. >Article: 97354
Please Give me outline of doing a project of dsp processor design.Article: 97355
I found the problem, it was due to a "dodgy" USB cable. I changed the cable and now all is well. Cheers, SimonArticle: 97356
Hi Ada, can you perform a timing simulation including timings and synthesis results of your FPGA ? You could at least see if timings of DQS, DQ, RasN/CasN/WeN/CsN , ClkP, ClkN are correct when coming out of the FPGA ... Rgds Andr=E9Article: 97357
Hi EDK 8.1 SP1 was made available already on 17 Feb so a few days earlier then expected, and PLB DDR2 memory IP core is now really included. some initial comments 1) the DDR2 IP core is different from MIG, so if MIG IP core required special loopback for the IDELAY calibration then the EDK DDR2 IP core requires DDR CLK feadback so there are different requirement for the PCB layout for DDR2 ip cores from MIG vs EDK 2) there DDR2 IP core documentation seems to be done in a rush, it still lists MCH_OPB (not PLB) in some cases and there is hint how to phase align of the CAL_CLK/4 should be, I would not like to use an extra DCM just to get 50MHz for the calibrate module, but I also dont know if is ok to use some not aligned clock for the CAL/4 3) the IDELAY_CTRL primitives seems to need handlocking constraints, at least on first attempts the design is unroutable :( AnttiArticle: 97358
reiner@hartenstein.de schrieb: > Firmware is instruction-stream-based - more precisely: > micro-instructions for programming the inner machine in a nested > machine, where an instruction of the outer machine is executed by a > sequence of micro-instruations by the inner machine. This may be your personal point of view, but this is not common sense. > Programming FPGAs etc., however is NOT instruction-stream-based (i. e. > NOT a procedural issue), and it should not be called "software" how > some people do, because a software compiler generates an instruction > schedule. Configuration code, however, is NOT an instruction schedule. > It is a structural issue (but NOT procedural). Right. > The sources for compilation into configuration code should be called > CONFIGWARE, and not software, nor firmware. A typical configware > compilation process uses placement and routing, however, NOT > instruction scheduling. > FPGA code I call configware code - the output of configware compilation > of design flow Welcome to the post-babylonian world ;-) Regards FalkArticle: 97359
reiner@hartenstein.de schrieb: > [...] Configuration code, however, is NOT an instruction schedule. > It is a structural issue (but NOT procedural). > >[...] A typical configware > compilation process uses placement and routing, however, NOT > instruction scheduling. Now, this discussion is going to become really interesting with multi context FPGAs. In that case there is a stream of very few very large instructions. Configware is ok, but I like stiffware better because it fits nicely between software, firmware and hardware. Kolja SulimmaArticle: 97360
Wow, I wouldn't use such a word...
stiffware
noun
1. computing.
Software that is difficult or impossible to modify because
it has been customized or there is incomplete documentation, etc.
Well, googlefight can confirm:
http://www.googlefight.com/index.php?lang=en_GB&word1=configware&word2=stiffware
Kolja Sulimma wrote:
> reiner@hartenstein.de schrieb:
>
>
>>[...] Configuration code, however, is NOT an instruction schedule.
>>It is a structural issue (but NOT procedural).
>>
>>[...] A typical configware
>>compilation process uses placement and routing, however, NOT
>>instruction scheduling.
>
>
> Now, this discussion is going to become really interesting with multi
> context FPGAs. In that case there is a stream of very few very large
> instructions.
>
> Configware is ok, but I like stiffware better because it fits nicely
> between software, firmware and hardware.
>
> Kolja Sulimma
Article: 97361Hello Groups, I am planning to use gigabit transceiver (Stratix GX), so wanted to know what additional glue logic i have to design around it. I think i need some glue for transmit part like synchronization, Packetization and idle data generation as i cannot feed raw data to the SERDES. Please let me know your suggestion. Any pointers to application note will also be great. Thanks and regards PraveenArticle: 97362
On 21 Feb 2006 01:06:44 -0800, Eric Smith <eric@brouhaha.com> wrote: >Peter Alfke wrote: >> Please read the very front of every Xilinx Data Book, where legal >> issues like copyright etc are mentioned on page 2, even before the >> table of content. >> The next-to-last paragraph says: >When the life support system fails, and the heirs sue the company that >made it, the doctor, the hospital, and the vendors of the components >of the system, Xilinx can point to that paragraph and tell the jury >"we tried to keep our customers from using our chips in life support >systems." The jury may or may not find that paragraph to reduce >Xilinx' liability. > >Personally, were I on a jury, I'd give that paragraph very little >weight. After all, the life support system has to be made out of >*something*. That said, however, if a particular component failed >and resulted in harm to a person, I'd ask why the designer of the >life support system hadn't designed the system to be fault tolerant >without that component being a single point of failure. Well, I don't see Xilinx trying to prevent customers from using their parts in life support systems. Instead, asking Xilinx for written consent would give Xilinx an opportunity to grant/withhold such consent, and to make conditions to be met before granting consent. Wild guess: such conditions would include accepting help regarding reliability, hard/soft failure rates, coding standards, possibly design review, etc to ensure both Xilinx and the customer had done everything possible to make a safe product. - BrianArticle: 97363
Marco T. wrote: > Hallo, > has someone used that controller with LwIP and a Xilinx FPGA? > > Where I could find some examples? > > Many Thanks > Marco > > Could you better describe your environment? You will certainly need some processor to execute this TCP/IP stack. We use the successor of this controller (LAN9118) and simpler and smaller version of LwIP called uIP. uIP is running on a OpenRISC processor which is implemented using a Xilinx Spartan-3 device. However, we currently use LwIP on various microcontrollers. Porting it to some other controller is mostly straightforward. There is a hardware implementation of a UDP/IP stack. Have a look at http://www.htwm.de/%7Elec/cgi-bin/twiki/view.cgi/Public/TcpIpStackAsic Regards, DominikArticle: 97364
Hal Murray wrote: >>The background for my question whether an FPGA is viewed as software or as >>hardware comes from the regulations for medical devices. > > > I'd call it firmware, the idea being that it's easier to change > than hardware but harder to change than software. But it depends > on who I'm talking to. If I wanted to be specific for somebody > familiar with the gear we are discussing, I'd probably call it > "the code for XXX" where XXX is the name of the particular FPGA. > Technically, the code for FPGAs is not firmware. Firmware is usually described as computer instructions or computer data. VHDL and Verilog are hardware descriptions. Once upon a time, we created a schematic to describe the logic we wanted and now we use a text editor. Logic descriptions and computer instructions are different things - though I admit the boundary sometimes gets a little blurry. Some teams at my company have developed FPGAs using a formal software development process. Though successful, the process matched our needs about as well as the process we use to develop circuit cards. FPGA development is a little bit of both worlds. To address your problem, you may need to cover both worlds. Sorry.Article: 97365
"Dominik Froehlich" <dfroehli@htwm.de> wrote in message news:dtf319$1q4$1@emma.aioe.org... > Marco T. wrote: >> Hallo, >> has someone used that controller with LwIP and a Xilinx FPGA? >> >> Where I could find some examples? >> >> Many Thanks >> Marco > > Could you better describe your environment? You will certainly need some > processor to execute this TCP/IP stack. > > We use the successor of this controller (LAN9118) and simpler and smaller > version of LwIP called uIP. uIP is running on a OpenRISC processor which > is implemented using a Xilinx Spartan-3 device. However, we currently use > LwIP on various microcontrollers. Porting it to some other controller is > mostly straightforward. > > There is a hardware implementation of a UDP/IP stack. Have a look at > http://www.htwm.de/%7Elec/cgi-bin/twiki/view.cgi/Public/TcpIpStackAsic > > > Regards, > Dominik The microcontroller is based on microblaze, with standalone software. MarcoArticle: 97366
Marko wrote: > Traditionally, firmware was defined as software that resided in ROM. > So, my question is, what do you call FPGA code? Is "firmware" > appropriate? James Morrison wrote: > The answer I came up with was "stiffware". reiner wrote: > FPGA code I call configware code - the output of configware compilation > of design flow At Pixel Velocity, we call it 'gateware'. --- Joe Samson Pixel VelocityArticle: 97367
Another good resource for standard video timing: http://www.hut.fi/Misc/Electronics/faq/vga2rgb/calc.html You can download the page and run it locally on your PC. It is often hard to get specifications for clocks per line, blanking intervals, sync time and polarity, etc. This page shows the values for most commonly used modes. The top drop-down menu allows you to select the known modes, or you can generate custom timing by entering data in the fields below. Good luck, Gabor Jan Panteltje wrote: > On a sunny day (20 Feb 2006 11:55:08 -0800) it happened "Jordi" > <a80x86@hotmail.com> wrote in > <1140465308.468125.76070@z14g2000cwz.googlegroups.com>: > > >Hi, > >thanks to all for the answers :) !!! (and sorry for my bad english :( > >) > > > >I think I'm begining to understand how it works. > > > >If the monitor uses PLL then the HSync frecuency determines how fast > >the monitor moves the beam.So if I increase the HSync frecuency the > >active time is shorter(and the back and front porch) but I can draw > >more lines per second so I can have better resolutions. I don't > >understand how resolution control works. The monitor has a fixed number > >of pixels(Let's supose a 1024x768 monitor). If I ouput 640x480 images > >and the monitor must draw 1024 pixels per line and 768 lines, then some > >pixels will be repeated. Isn't it? > > Yes in an analog monitor there will be an 'aliasing' effect. > Some LCD monitors and TVs will use digital processing to recalculate the picture > for the resolution these themselves have. > In such a case the timing requirements for the input format may be more strict, > like for example a specific TV standard. > > In an analog monitor it is very possible to have 'half a pixel' on (if enough bandwidth): > > -- -- -- -- -- -- -- -- -- shadow mask > --- --- --- --- --- --- --- video signal > This 'half on' gives a brightness change at that pixel location. > > The intensity of the ascanning electron beam is just modulated by the video. > > In a LCD this is not the case, but the pixel brigtness can be corrected accordingly by > processing.Article: 97368
I hate to break it to you buddy, but partial configuration has crashed in every version, every service pack, I've ever attempted it on. I have yet to try it on 8.1, but on all other versions of ISE you can safely assume that it is busted. It was a sales pitch, not an engineering priority for Xilinx. Your best chance of getting it to work is for the case of additional logic only -- change any net names or instance names and it will certainly crash. It seems like my errors all looked like the one you posted. I've received the errors on Win2k and WinXP with both Xeon hardware and AthlonXP hardware.Article: 97369
Hi!
A while back sombody posted about problems with his Xilinx USB cable
It took some time to get it working, there are several issues.
see: http://gentoo-wiki.com/HOWTO_Xilinx for a complete install-howto
This is just the part I added:
Trouble shooting the ds300 and XUP-V2P usb-interface
Not all of these steps are needed:
* Run "bash <ise install dir>/bin/lin/setup_pcusb" as root to
install the USB drivers
* Install fxload in /sbin see:
http://prdownloads.sourceforge.net/linux-hotplug/
* Put the absolute path to the firmware:
/etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex in /etc/hotplug/usb/xusbdfwu
* chmod 666 /dev/ttyUS*
HTH Groetjes,
Stefan
Article: 97370I've heard it referred to as gateware for a long time where I work. I think that's a fine name.Article: 97371
> call it 'gateware' same at Starbridge Sys.Article: 97372
I've called it "gateware" for the last 15 years.Article: 97373
Hmm.. after a reboot it doesn't seem to be working anymore so close... I will keep trying... Groetjes, StefanArticle: 97374
Bryan, I posted a question about this technique in a response to a separate thread (multiphase data extraction question). I'm using this to gain access to the IDDRs associated with both pads of a diff pair, so I can sample the input on four phases of a clock, with very low skews in the data paths. Do you recommend separate ibufds primitives, or a single ibufds_diff_out primitive? Andy Jones
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