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
raso wrote: > Dear Jan, > > This part is not a problem at all. > > What I need to do is to keep the number of 2Khz pulses > same as the main 50Hz changes. In perfect condition > there are fourty 2Khz cycles within one 50Hz period (20ms/500us). > When 50Hz changes (+/- 0.5Hz), 2KHz pulse period should also > chance accordingly to stay in lock. > > My system clock is 60MHz. I implemented a JK phase detector, a > K-counter and a DCO in order to generate 2KHz pulses and this system > operates at system clock. The > output locks to exact 50Hz very quickly (fed from signal generator), > but when I change the reference clock to, lets say, 50.1Hz it starts > drifting. You will also get phase jitter on Mains 50Hz references, as well as the frequency drifts - in most countries they try and keep the number of cycles in a day correct, for operating clocks. So, you need to realise this will always be a historical-fit based lock. What you decide for the next mains cycle might not actually be correct, but you can make a best guess based on the pevious ones. With MHz to burn, and FPGA, why not use a Freqency Counter/IndexCounter/LoadableDivider, with a slow tracking Up/down coounter on the index. It can be 100% digital, and the tracking speed becomes the PLL-LPF. Looks like you need to track 1% dF, keeping a nominal 40 clocks / cycle, with a possible divide of 30,000 (!), that should be do-able :) Many mains systems use zero crossing phase lock, and do not bother about the small freqency variations. -jgArticle: 105551
Hi Folks, Does anybody has any experience with uClinux running on Virtex4FX12 (ML403?) in PPC 405 processor. Can the LL_TEMAC drivers be connected to the OS if I have a normal Linux version drivers? I want to get it running on GSRD2 on Avnet Virtex-4 Mini-Module, because FLASH for standalone operation is only 4MB deep. This is not enough for any other OS with TCP/IP support (or a TCP/IP stack). Cheers, GuruArticle: 105552
Finally after two weeks I have configured the board for the first time. I was misled that software update was performed every time I start the ISE with WebUpdate, but that was not the case - after you mentioned SP (it was not the one for Windows XP) I went to the update section of the web site and installed SP 3. I am able to generate ACE files that work. Can I interface the board's J6 header single ended signal connections with the parallel port on the PC with no buffer and what constrains should be asserted for those pins? Thanks for all your help, Dan Ed McGettigan wrote: > EEngineer wrote: > > I use: > > > > Service Pack 1 > > > > I would definitely try upgrading to Service Pack 3. > > Ed McGettigan > -- > Xilinx Inc.Article: 105553
Hi Jon, Falk Brunner sent me his VHDL implementation of 74LS297. I modified it so that K-counter and I/D counter (DCO) run at system clock which is 30MHz. The system has following blocks; - The first component is an JKFF based phase detector. - Then, there is a K-counter operating at 30MHz. With 30MHz clock, a full 50Hz period means M=30e6/50=600000 ticks. For minimum jitter, modulus of K counter is set M/2 which is 300000. The borrow pulse decreases the modulus of I/D counter (2KHz DCO) while carry pulse increases it by 1. So in locked condition, it generates 1 carry and 1 borrow pulse within one 50Hz period and they cancel each other. - I/D counter is a DCO (modulus counter). It operates at 30MHz. When it is locked to 50Hz it has modulus of 15000. When 50Hz changes, the borrow and carry pulses should adjust the modulus of I/D counter (carry pulse increases the modulus by 1, and borrow decreases it by 1). By this way, period of 2kHz pulses is adjusted according to 50Hz input. - N-Counter which devides 2Khz clock by 40. The only parameter that I can play with is the modulus of K counter. I can't use direct implementation of 74LS297. Because, it syncronises f_in and f_out by inserting or deleting 2KHz pulses (I/D pulses). I can't tolerate inserting or deleting 2KHz pulses. It has to keep the number of 2kHz pulses as 40 in each 50Hz period. Isa Jon Elson wrote: > raso wrote: > > >Hello everyone, > > > >I would like to ask if it is possible to generate 2Khz clock signal > >from 50Hz main frequency > >using an ADPLL. I have tried SN297 circuit implementation, but couldn't > >achieve it. > > > > > The 74LS297 has a VERY narrow lock range, compared to traditional > analog PLL's. It is generally a fraction of a percent, but I think there > is a setting that gives you a couple percent range. It works fine for > syncing between a data source running on one xtal clock, from another > xtal clock. You would need a digital clock (quartz crystal) that is at > some multiple of 50 Hz (not too hard). Then, you'd need a couple of > long counter chains to do the divide down. > > Are you using an HLL library version of the 74LS297 circuit? If so, > where did you get it? I happen to use the real TI chip in one device I > built, and a synthesizable version might be good to know about. > > JonArticle: 105554
Dear Jim, Could you please explain your idea below? >> With MHz to burn, and FPGA, why not use a >> Freqency Counter/IndexCounter/LoadableDivider, with a slow tracking >> Up/down coounter on the index. >> It can be 100% digital, and the tracking speed becomes the PLL-LPF. Many thanks, Isa Jim Granville wrote: > raso wrote: > > Dear Jan, > > > > This part is not a problem at all. > > > > What I need to do is to keep the number of 2Khz pulses > > same as the main 50Hz changes. In perfect condition > > there are fourty 2Khz cycles within one 50Hz period (20ms/500us). > > When 50Hz changes (+/- 0.5Hz), 2KHz pulse period should also > > chance accordingly to stay in lock. > > > > My system clock is 60MHz. I implemented a JK phase detector, a > > K-counter and a DCO in order to generate 2KHz pulses and this system > > operates at system clock. The > > output locks to exact 50Hz very quickly (fed from signal generator), > > but when I change the reference clock to, lets say, 50.1Hz it starts > > drifting. > > You will also get phase jitter on Mains 50Hz references, as well as > the frequency drifts - in most countries they try and keep the number of > cycles in a day correct, for operating clocks. > So, you need to realise this will always be a historical-fit based > lock. What you decide for the next mains cycle might not actually be > correct, but you can make a best guess based on the pevious ones. > > With MHz to burn, and FPGA, why not use a > Freqency Counter/IndexCounter/LoadableDivider, with a slow tracking > Up/down coounter on the index. > It can be 100% digital, and the tracking speed becomes the PLL-LPF. > > Looks like you need to track 1% dF, keeping a nominal 40 clocks / cycle, > with a possible divide of 30,000 (!), that should be do-able :) > > Many mains systems use zero crossing phase lock, and do not bother about > the small freqency variations. > > -jgArticle: 105555
EEngineer wrote: > Finally after two weeks I have configured the board for the first time. > I was misled that software update was performed every time I start the > ISE with WebUpdate, but that was not the case - after you mentioned SP > (it was not the one for Windows XP) I went to the update section of the > web site and installed SP 3. I am able to generate ACE files that work. > > Can I interface the board's J6 header single ended signal connections > with the parallel port on the PC with no buffer and what constrains > should be asserted for those pins? > I'm glad that you are moving forward with your design work. On the second item the answer is no as a parallel port is 5V and the IOs on the headers are 2.5V (or 3.3V if you move a jumper). Ed McGettigan -- Xilinx Inc.Article: 105556
Symon wrote: > From this, and if I don't use any receivers in the column, I deduce that I > can leave AVCCAUXRXA unfiltered. Right? From the paragraph immediately above the one you quoted, I'm assuming so in my design as well... 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: 105557
raso wrote: > Dear Jim, > > Could you please explain your idea below? > > >>>With MHz to burn, and FPGA, why not use a >>>Freqency Counter/IndexCounter/LoadableDivider, with a slow tracking >>>Up/down coounter on the index. >>>It can be 100% digital, and the tracking speed becomes the PLL-LPF. In broad terms: Table method: Measure 50Hz (half?) period. appx 50KHz timebase resolves to 0.1% eg gets 20.2ms : Trim and Scale the result, into a lookup table, that then loads the 2KHz divider. ( Suppose you target improve of +/- 1% to +/- 0.1%, that is a ~20 entry table. Keeping to 0.1%, 2KHz to 0.1% is 2MHz Clock, with ~1000 divider values. Table/ROM has 20 entries, of 11 bit binary values. Each new cycle uses the last cycles period, to get a best fit of 40 '2Khz' clocks. Tracking counter Method : Count the 2KHz clocks you actually get, in a 50Hz period. For 2KHz, create an 11 bit Divider(from 2MHz), fed from an 11 bit Up/Dn counter. If the Counts_2Khz is ABOVE 40, then Increment the Up/Dn counter, if it is BELOW 40, decrement the Up/Dn counter. ( for higher precision, you might count higher in the divider than 2Khz - you have not given desired jitter/precision values ) These lock frequecy, or cycles, but do not lock phase. Most main systems will reset/load the 2KHz on zero cross, to phase lock that. You also want to freqency lock, to have a known phase stepping. -jg > > > Many thanks, > Isa > > Jim Granville wrote: > >>raso wrote: >> >>>Dear Jan, >>> >>>This part is not a problem at all. >>> >>>What I need to do is to keep the number of 2Khz pulses >>>same as the main 50Hz changes. In perfect condition >>>there are fourty 2Khz cycles within one 50Hz period (20ms/500us). >>>When 50Hz changes (+/- 0.5Hz), 2KHz pulse period should also >>>chance accordingly to stay in lock. >>> >>>My system clock is 60MHz. I implemented a JK phase detector, a >>>K-counter and a DCO in order to generate 2KHz pulses and this system >>>operates at system clock. The >>>output locks to exact 50Hz very quickly (fed from signal generator), >>>but when I change the reference clock to, lets say, 50.1Hz it starts >>>drifting. >> >> You will also get phase jitter on Mains 50Hz references, as well as >>the frequency drifts - in most countries they try and keep the number of >>cycles in a day correct, for operating clocks. >> So, you need to realise this will always be a historical-fit based >>lock. What you decide for the next mains cycle might not actually be >>correct, but you can make a best guess based on the pevious ones. >> >>With MHz to burn, and FPGA, why not use a >>Freqency Counter/IndexCounter/LoadableDivider, with a slow tracking >>Up/down coounter on the index. >>It can be 100% digital, and the tracking speed becomes the PLL-LPF. >> >>Looks like you need to track 1% dF, keeping a nominal 40 clocks / cycle, >>with a possible divide of 30,000 (!), that should be do-able :) >> >>Many mains systems use zero crossing phase lock, and do not bother about >>the small freqency variations. >> >>-jg > >Article: 105558
hi everyone, for my class project i need to build a model in simulink , using xilinx system generator blocks..which computes matrix multiplication about 512X512 size...can anyone help me how to do it with black box.........i tried Mcode but didnt work........... thanks in advanceArticle: 105559
I've got a problem at work where the FPGA group is at war with the hardware group and I am sick and tired of ducking the punches. I designed the board although there was not a lot of original design. I was told what main chips to use since they had done a similar design before. So I pretty much copied the design which uses an XC3S400-4 and a TMS320VC5510 with a combined SRAM/Flash chip. I am being asked for a proper bus timing analysis and I need the data on the FPGA. That is where the punches start flying! The bus is asynchronous, but for whatever reason, the FPGA designers originally chose to use the CLKOUT from the DSP as the interface clock rather than the other clock being provided to the FPGA. This may be because although the DSP memory interface is designed to work with async bus devices like RAMs and Flash, all the timing parameters are WRT the DSP CLKOUT. However, the timings are such that you can't use CLKOUT to clock in the signals in a synchronous manner. The signal transitions are on the rising clock edge +- a few ns. The clock is about 10 ns period. When it is matched to the FPGA IO timing I don't think you can meet the setup and hold times from what I have seen and I am told the design double clocks all inputs to remove metastability. To do the timing analysis, I have asked the FPGA group to provide timing data on the FPGA. I expected them to come back with the data they are using for timing constraints. Instead they basically told me "you don't need no stinkin' timing data". They seem to feel that because we are using lots of clock cycles on the bus cycle, the detailed timing is not important. We have gone around a few times and I continue to assert that there are a few parameters that I need from the FPGA design such as the time from the RD_N signal rising to the data out going high-Z. After half a dozen emails, I finally got an answer of 16 ns. But I realized that I can't believe this since it was presented as a measurement from one iteration of the design. I looked at the timing constraints and they don't have any other than the clocks! Today in a meeting the FPGA supervisor told me that this timing parameter was from the Spartan data sheet since it is the time from a clock input through an IOB FF that controls the tristate buffer. When I checked the data sheet I can't find such a timing parameter and the data I do find says the time in the IOB itself is less than 1 ns under the given conditions. "Time from the active transition at the OTCLK input of the Three-state Flip-Flop (TFF) to when the Output pin enters the high-impedance state (LVCMOS25, 12mA output drive, Fast slew rate) All 0.28 0.74 0.85 ns" Our interface is 3.3 volts and the worst case adjustment I can find is "LVTTL Slow 2 mA 2.76 7.27 8.36 ns". So we still end up at well less than 10 ns without counting the clock delay. They seem to be using the DCMs, but I can't say how they have them set up. Even so, with the DCM the clock input to output pin (through an IOB FF) is under 2 ns and even without the DCM it is under 5 ns. So giving the most leeway I possibly can I still come up with less than 15 ns for clock to output high-Z compared to 16 ns. That leaves these possibilities... 1) I don't know what I am doing and the above rational is full of holes. 2) This supervisor is incompetent. 3) This supervisor is deliberately misleading us to cover someone else's incompetence. 4) ??? I am getting so tired of having to sift through the BS that the other departments are feeding me that I am close to quitting. But before I do, I want to get to the bottom of this. Have I completely misunderstood how the tristate outputs work somehow? Is there a number in the data sheet that justifies the 16 ns number somewhere? In reality I expect this signal path is going through logic inside the chip and is not being clocked in the IOB. The 16 ns number most likely came from a measurement of one iteration of the chip. I may take the time to dig into the design files at some point. But first I would just like to get a sanity check on the idea that the 16 ns number came from the data sheet as a path from the clock input to an output going high-Z. So who is nuts, me or the other guy??? (or is it both? ;^)Article: 105560
First of all, calm down! Next, it's not clear from your post what the interface timing requirements are. Does the FPGA terminate the bus cycles or is the cycle timing fixed (either hard-wired or programmed in the DSP)? Regardless, there are only a few critical timing parameters on an interface like this. On write cycles the FPGA has to latch the write data before it goes away, and on read cycles it has to present valid data to the DSP when the DSP is latching it, and it has to get off the bus before another device tries to drive it. On write cycles I usually try to detect the start of the write cycle (e.g., falling edge of cs/ with the rd_wr/ line low), synchronize it, and turn it into a 1-cycle pulse used as a clock enable to latch the write data. The only analysis needed is to make sure the write data is still valid at the latching flip-flops when the 1-cycle pulse is asserted under all possible timing circumstances. And you have to know how to generate that pulse correctly. On reads, I don't understand the obsession with an exact number for the OBUF turn-off time. Personally I wouldn't even do that synchronously. I would just use the cs/ from the DSP directly as the oe/ for the OBUFs (qualified, of course, so that the FPGA only drives the bus during read cycles). Making that path combinational makes the timing contraints easier, and the static timing report will indicate clearly for each re-route if you made the constraint or not. All you need is a max pad-to-pad delay such that the FPGA quits driving within ??ns of the deassertion of cs/. The tools will take into account the worst-case OBUF turn-off time. The timing analysis and constraints get more complicated with an async bus if you generate a clocked oe/. As the board designer you should be telling the FPGA group the interface timing they have to meet, so what you're doing sounds like the tail wagging the dog anyway. You give them numbers and they tell you whether or not they can meet them. I've seen you post before about these "wars" at work. Sounds like a bunch of b.s. turf wars to me. Do yourself a favor and move on. Rob "rickman" <spamgoeshere4@yahoo.com> wrote in message news:1153876482.253224.323960@s13g2000cwa.googlegroups.com... > I've got a problem at work where the FPGA group is at war with the > hardware group and I am sick and tired of ducking the punches. I > designed the board although there was not a lot of original design. I > was told what main chips to use since they had done a similar design > before. So I pretty much copied the design which uses an XC3S400-4 and > a TMS320VC5510 with a combined SRAM/Flash chip. I am being asked for a > proper bus timing analysis and I need the data on the FPGA. That is > where the punches start flying! > > The bus is asynchronous, but for whatever reason, the FPGA designers > originally chose to use the CLKOUT from the DSP as the interface clock > rather than the other clock being provided to the FPGA. This may be > because although the DSP memory interface is designed to work with > async bus devices like RAMs and Flash, all the timing parameters are > WRT the DSP CLKOUT. However, the timings are such that you can't use > CLKOUT to clock in the signals in a synchronous manner. The signal > transitions are on the rising clock edge +- a few ns. The clock is > about 10 ns period. When it is matched to the FPGA IO timing I don't > think you can meet the setup and hold times from what I have seen and I > am told the design double clocks all inputs to remove metastability. > > To do the timing analysis, I have asked the FPGA group to provide > timing data on the FPGA. I expected them to come back with the data > they are using for timing constraints. Instead they basically told me > "you don't need no stinkin' timing data". They seem to feel that > because we are using lots of clock cycles on the bus cycle, the > detailed timing is not important. We have gone around a few times and > I continue to assert that there are a few parameters that I need from > the FPGA design such as the time from the RD_N signal rising to the > data out going high-Z. After half a dozen emails, I finally got an > answer of 16 ns. But I realized that I can't believe this since it was > presented as a measurement from one iteration of the design. I looked > at the timing constraints and they don't have any other than the > clocks! > > Today in a meeting the FPGA supervisor told me that this timing > parameter was from the Spartan data sheet since it is the time from a > clock input through an IOB FF that controls the tristate buffer. When > I checked the data sheet I can't find such a timing parameter and the > data I do find says the time in the IOB itself is less than 1 ns under > the given conditions. > > "Time from the active transition at the OTCLK input of the Three-state > Flip-Flop (TFF) to when the Output pin enters the high-impedance state > (LVCMOS25, 12mA output drive, Fast slew rate) All 0.28 0.74 0.85 ns" > > Our interface is 3.3 volts and the worst case adjustment I can find is > "LVTTL Slow 2 mA 2.76 7.27 8.36 ns". So we still end up at well less > than 10 ns without counting the clock delay. They seem to be using the > DCMs, but I can't say how they have them set up. Even so, with the DCM > the clock input to output pin (through an IOB FF) is under 2 ns and > even without the DCM it is under 5 ns. So giving the most leeway I > possibly can I still come up with less than 15 ns for clock to output > high-Z compared to 16 ns. > > That leaves these possibilities... > 1) I don't know what I am doing and the above rational is full of > holes. > 2) This supervisor is incompetent. > 3) This supervisor is deliberately misleading us to cover someone > else's incompetence. > 4) ??? > > I am getting so tired of having to sift through the BS that the other > departments are feeding me that I am close to quitting. But before I > do, I want to get to the bottom of this. Have I completely > misunderstood how the tristate outputs work somehow? Is there a number > in the data sheet that justifies the 16 ns number somewhere? > > In reality I expect this signal path is going through logic inside the > chip and is not being clocked in the IOB. The 16 ns number most likely > came from a measurement of one iteration of the chip. I may take the > time to dig into the design files at some point. But first I would > just like to get a sanity check on the idea that the 16 ns number came > from the data sheet as a path from the clock input to an output going > high-Z. > > So who is nuts, me or the other guy??? (or is it both? ;^) >Article: 105561
Rickman - sorry you have to deal with such annoyances. I'm a stickler for well defined I/O constraints so I see shoddy engineering on the part of the FPGA group, but that's me. The "data sheet" is probably not what you think. The Timing Analyzer within the Xilinx tool suite has a section at the end that summarizes data input setup and hold times as well as clock-to-out for all the various signals. I believe the clock and clock edge are included as well. While I specify my PCI numbers with one value in my constraints for Tcko and another for the turnaround cycle - Toff - it's the longest value that ends up in the "Data Sheet" section of the Timing Analyzer report which would be the Ton/Toff. It's probably the timing for one *iteration* of the FPGA but worst case values, not measured. As long as the design doesn't budge, great. Otherwise, the next rev could move the unconstrained I/O around one direction or another. rickman wrote: > I've got a problem at work where the FPGA group is at war with the > hardware group and I am sick and tired of ducking the punches. I > designed the board although there was not a lot of original design. I > was told what main chips to use since they had done a similar design > before. So I pretty much copied the design which uses an XC3S400-4 and > a TMS320VC5510 with a combined SRAM/Flash chip. I am being asked for a > proper bus timing analysis and I need the data on the FPGA. That is > where the punches start flying! > > The bus is asynchronous, but for whatever reason, the FPGA designers > originally chose to use the CLKOUT from the DSP as the interface clock > rather than the other clock being provided to the FPGA. This may be > because although the DSP memory interface is designed to work with > async bus devices like RAMs and Flash, all the timing parameters are > WRT the DSP CLKOUT. However, the timings are such that you can't use > CLKOUT to clock in the signals in a synchronous manner. The signal > transitions are on the rising clock edge +- a few ns. The clock is > about 10 ns period. When it is matched to the FPGA IO timing I don't > think you can meet the setup and hold times from what I have seen and I > am told the design double clocks all inputs to remove metastability. > > To do the timing analysis, I have asked the FPGA group to provide > timing data on the FPGA. I expected them to come back with the data > they are using for timing constraints. Instead they basically told me > "you don't need no stinkin' timing data". They seem to feel that > because we are using lots of clock cycles on the bus cycle, the > detailed timing is not important. We have gone around a few times and > I continue to assert that there are a few parameters that I need from > the FPGA design such as the time from the RD_N signal rising to the > data out going high-Z. After half a dozen emails, I finally got an > answer of 16 ns. But I realized that I can't believe this since it was > presented as a measurement from one iteration of the design. I looked > at the timing constraints and they don't have any other than the > clocks! > > Today in a meeting the FPGA supervisor told me that this timing > parameter was from the Spartan data sheet since it is the time from a > clock input through an IOB FF that controls the tristate buffer. When > I checked the data sheet I can't find such a timing parameter and the > data I do find says the time in the IOB itself is less than 1 ns under > the given conditions. > > "Time from the active transition at the OTCLK input of the Three-state > Flip-Flop (TFF) to when the Output pin enters the high-impedance state > (LVCMOS25, 12mA output drive, Fast slew rate) All 0.28 0.74 0.85 ns" > > Our interface is 3.3 volts and the worst case adjustment I can find is > "LVTTL Slow 2 mA 2.76 7.27 8.36 ns". So we still end up at well less > than 10 ns without counting the clock delay. They seem to be using the > DCMs, but I can't say how they have them set up. Even so, with the DCM > the clock input to output pin (through an IOB FF) is under 2 ns and > even without the DCM it is under 5 ns. So giving the most leeway I > possibly can I still come up with less than 15 ns for clock to output > high-Z compared to 16 ns. > > That leaves these possibilities... > 1) I don't know what I am doing and the above rational is full of > holes. > 2) This supervisor is incompetent. > 3) This supervisor is deliberately misleading us to cover someone > else's incompetence. > 4) ??? > > I am getting so tired of having to sift through the BS that the other > departments are feeding me that I am close to quitting. But before I > do, I want to get to the bottom of this. Have I completely > misunderstood how the tristate outputs work somehow? Is there a number > in the data sheet that justifies the 16 ns number somewhere? > > In reality I expect this signal path is going through logic inside the > chip and is not being clocked in the IOB. The 16 ns number most likely > came from a measurement of one iteration of the chip. I may take the > time to dig into the design files at some point. But first I would > just like to get a sanity check on the idea that the 16 ns number came > from the data sheet as a path from the clock input to an output going > high-Z. > > So who is nuts, me or the other guy??? (or is it both? ;^)Article: 105562
Guru schrieb: > Hi Folks, > > Does anybody has any experience with uClinux running on Virtex4FX12 > (ML403?) in PPC 405 processor. Can the LL_TEMAC drivers be connected to > the OS if I have a normal Linux version drivers? > I want to get it running on GSRD2 on Avnet Virtex-4 Mini-Module, > because FLASH for standalone operation is only 4MB deep. This is not > enough for any other OS with TCP/IP support (or a TCP/IP stack). > > Cheers, > > Guru there is no uClinux for the PPC. If you want to have PPC to be used you have to have Linux on it. http://www.hydraxc.com the -50 modules are shipped with PPC-linux reference design, the image is actually smaller than microblaze-uclinux. And yes it includes networking support. I think the ppc-linux image is 1.3MB so it would easily fits into 4MB flash. Too bad that the friend of John Williams did decide to remove the website with that PPC-linux distribution from the internet, so that download is no longer available. AnttiArticle: 105563
MKULTRA2@gmail.com wrote: > Hi Kida, > > not sure about the first one. For your second question, you can use XPS > to customize the linker script: Software -> Generate Linker Script. > Alternatively you can code it by hand. The linker script contains what > memories all the software sections sit in. You must include your other > memories as EDK-compliant peripherals in the system before they will > appear in the GLS wizard drop-downs. I hope that can at least point you > in the right direction. > -scott > > vlsi_kida@math.net wrote: > > Hi Gurus, > > > > I am new to EDK and embedded software > > please help me... > > > > I am trying some example and test applications using EDK. > > I have following Queries... > > > > 1. I have my application written in C, I want to view its assembly > > output instead of .elf > > where I can set the option to get assembly output....? > > > > 2. presently all the applications are running through internal BRAM. > > If I want to map the application or part of application in external > > sdram > > how do I do it...? > > > > > > Thanks and Regards, > > Kida For the first one, you can either use mb-objdump/powerpc-eabi-objdump command in Xilinx shell to dump the ELf to ASM, or use the GDB GUI to see the ASM code.Article: 105564
Kyle H. wrote: > Hello All, > > I am having a hard time understanding EDK ---> FPGA tool flow (I > think). I am using EDK/ISE 8.1, testing the Generic Reference Design > from Memec/Avnet. It is for the Xilinx FX12 mini-module. > > I have been able to use the drivers supplied to control the LCD screen, > rs232 uart and the user LEDs as expected. But when it comes to a > specific FPGA pin of my choice I'm getting lost. > > I first started out with their example, and created my own spin off of > theirs, trying to learn my way around the IDE of EDK. All is working > well except my understanding of the UCF file corresponding to the data > inside EDK. Ok, so in my xparameters.h file I see there are > refferencing the memory locations for each component in the system > assembly. So in C I can assign these "registers" via the drivers and > get expected results. When it comes down to bit by bit I am lost. > > Is the UCF file that I'm using generated by EDK, or did someone from > memec hand sculpt this? > Maybe I have to import this into an ISE project to get the big picture? > > When I assign a gpio output 0x0550 I can see one 5 on my FPGA pins, but > not in the order I would expect it. Really it's not a five at all, > unless I'm reading all the even pins. And I thought the gpio output > was 32 bit, so why in the UCF file is there only 10 pins assigned to > the gpio output port(s)? > Since the PPC is big-endian, the output order of GPIO should be inversed as you expected. > I hope I am not being to vague/mis-guided, and even confusing you guys. > Because I have certianly exhausted my confusion. I've also read over a > ton of documentation from XIlinx, about EDK, the drivers, etc... I was > searching for that golden document that would tell me exactly what I > needed to know and I havn't found it yet. Maybe I am not looking for > the correct topics in the manuals? Maybe I need to read over PowerPC > user guide a bit more? > Help point me in the wright direction! > > Thanks, > KyleArticle: 105565
Pasacco wrote: > hi > > I have problem when opening "old" project file, system.xmp, using XPS > 6.3. > > It seems that "HW_VER" is not set up for each IP for this particular > version of EDK. > How can we know what is correct (or latest) version of each IPs? > > thankyou > Check the \hw folder in EDK installation directory for all of the IP released with EDK. > ------------------------------------------------------------------------------------------------------------------------------- > PM_SPEC -- Xilinx path component is <C:/EDK> > ERROR:MDT - ppc405 (ppc405_i) - C:\Xilinx\Work_July07\system.mhs:159 - > PORT TIEC405DISOPERANDFWD not found in mpd. > ERROR:MDT - ppc405 (ppc405_i) - C:\Xilinx\Work_July07\system.mhs:167 - > PORT TIEC405MMUEN not found in mpd. > ERROR:MDT - jtagppc_cntlr (jtag_cntl) - > C:\Xilinx\Work_July07\system.mhs:187 - PORT DBGC405DEBUGHALT not found > in mpd. > ERROR:MDT - jtagppc_cntlr (jtag_cntl) - > C:\Xilinx\Work_July07\system.mhs:188 - PORT JTGC405TRSTNEG not found in > mpd. > ERROR:MDT - jtagppc_cntlr (jtag_cntl) - > C:\Xilinx\Work_July07\system.mhs:189 - PORT JTGC405TCK not found in > mpd. > ERROR:MDT - jtagppc_cntlr (jtag_cntl) - > C:\Xilinx\Work_July07\system.mhs:190 - PORT JTGC405TDI not found in > mpd. > ERROR:MDT - jtagppc_cntlr (jtag_cntl) - > C:\Xilinx\Work_July07\system.mhs:191 - PORT JTGC405TMS not found in > mpd. > ERROR:MDT - jtagppc_cntlr (jtag_cntl) - > C:\Xilinx\Work_July07\system.mhs:192 - PORT C405JTGTDO not found in > mpd. > ERROR:MDT - jtagppc_cntlr (jtag_cntl) - > C:\Xilinx\Work_July07\r\system.mhs:193 - PORT C405JTGTDOEN not found in > mpd. > ERROR:MDT - jtagppc_cntlr (jtag_cntl) - > C:\Xilinx\Work_July07\system.mhs:194 - PORT RSTC405RESETSYS not found > in mpd. > ERROR:MDT - jtagppc_cntlr (jtag_cntl) - > C:\Xilinx\Work_July07\system.mhs:196 - PORT HALTNEG not found in mpd. > ERROR:MDT - ppc405 (ppc405_i2) - C:\Xilinx\Work_July07\system.mhs:306 - > PORT TIEC405DISOPERANDFWD not found in mpd. > ERROR:MDT - ppc405 (ppc405_i2) - C:\Xilinx\Work_July07\system.mhs:314 - > PORT TIEC405MMUEN not found in mpd.Article: 105566
The only reference design for V4MM (from uCLinux website) uses MB (too bad). But the source files for uClinux include also the support for PPC, but I don't know if it is a working version. hydraXC-50 probably has the uClinux preloaded (although it is written that all the designs inluce MB and uClinux), but see the price (double!!). I guess I have to contact John Williams on this matter. Thanks, Guru Antti wrote: > Guru schrieb: > > > Hi Folks, > > > > Does anybody has any experience with uClinux running on Virtex4FX12 > > (ML403?) in PPC 405 processor. Can the LL_TEMAC drivers be connected to > > the OS if I have a normal Linux version drivers? > > I want to get it running on GSRD2 on Avnet Virtex-4 Mini-Module, > > because FLASH for standalone operation is only 4MB deep. This is not > > enough for any other OS with TCP/IP support (or a TCP/IP stack). > > > > Cheers, > > > > Guru > > there is no uClinux for the PPC. > If you want to have PPC to be used you have to have Linux on it. > > http://www.hydraxc.com > > the -50 modules are shipped with PPC-linux reference design, the image > is actually smaller than microblaze-uclinux. And yes it includes > networking support. I think the ppc-linux image is 1.3MB so it would > easily fits into 4MB flash. Too bad that the friend of John Williams > did decide to remove the website with that PPC-linux distribution from > the internet, so that download is no longer > available. > > AnttiArticle: 105567
Antti, I can see you are personally involved in development, that's why you have good info on this matter. The modules look VERY good (full of features), only the price bothers me. I cannot move to another platform right now, because my hardware is designed for Mini-Module. I guess I will have to implement the PPC-uClinux by myself :( Cheers, Guru Antti wrote: > Guru schrieb: > > > Hi Folks, > > > > Does anybody has any experience with uClinux running on Virtex4FX12 > > (ML403?) in PPC 405 processor. Can the LL_TEMAC drivers be connected to > > the OS if I have a normal Linux version drivers? > > I want to get it running on GSRD2 on Avnet Virtex-4 Mini-Module, > > because FLASH for standalone operation is only 4MB deep. This is not > > enough for any other OS with TCP/IP support (or a TCP/IP stack). > > > > Cheers, > > > > Guru > > there is no uClinux for the PPC. > If you want to have PPC to be used you have to have Linux on it. > > http://www.hydraxc.com > > the -50 modules are shipped with PPC-linux reference design, the image > is actually smaller than microblaze-uclinux. And yes it includes > networking support. I think the ppc-linux image is 1.3MB so it would > easily fits into 4MB flash. Too bad that the friend of John Williams > did decide to remove the website with that PPC-linux distribution from > the internet, so that download is no longer > available. > > AnttiArticle: 105568
"sirisha.aluru@gmail.com" <sirisha.aluru@gmail.com> writes: > hi everyone, > for my class project i need to build a model in simulink , using xilinx > system generator blocks..which computes matrix multiplication about > 512X512 size...can anyone help me how to do it with black box.........i > tried Mcode but didnt work........... > thanks in advance > I don't think using a black box will help you (unless you already have some HDL code that does what you want, but it sounds like you don't). You need to design the circuit to multiply 2 matrices. Do you know how to multiply matrices on paper? If not, find that out first! If so, write down the steps you do in lots of detail. This should give you an idea for some counters and memory accesses. Prototype it in Excel, or C, or Matlab or something high-leve until you understand exactly how it's going to work. Then putting the Sysgen blocks down and wiring them up should be very straightforward. HTH! Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conektArticle: 105569
Guru schrieb: > Antti, > > I can see you are personally involved in development, that's why you > have good info on this matter. > The modules look VERY good (full of features), only the price bothers > me. > I cannot move to another platform right now, because my hardware is > designed for Mini-Module. > I guess I will have to implement the PPC-uClinux by myself :( > > Cheers, > > Guru read what I wrote - PPC-linux (not uClinux) image is 1.3MB only so it would work on V4MM also. all hydraXC-xx modules come with support DVD that includes VMWare preconfigured environments so building a new MB-uclinux or PPC-linux kernel for the hydraXC modules is only the matter of typing make :) -- there is no PPC-uclinux ASFAIK and I see no reason on even working on it. AnttiArticle: 105570
"Mark McDougall" <markm@vl.com.au> wrote in message news:44c6b5a3$0$23525$5a62ac22@per-qv1-newsreader-01.iinet.net.au... > Symon wrote: > >> From this, and if I don't use any receivers in the column, I deduce that >> I >> can leave AVCCAUXRXA unfiltered. Right? > > From the paragraph immediately above the one you quoted, I'm assuming so > in my design as well... > > Regards, > > -- > Mark McDougall, Engineer Mark, Yep, the more I read it, the more I'm convinced that's what they mean. A nice little diagram showing what's powered from what would be a nice addition to the user guide! Cheers, Syms.Article: 105571
Wasn't the whole Idea of uClinux to have a port to chip without memory management? If this is true, a uClinux would cripple the PowerPC. Might as well use the real thing. -Eli Antti wrote: > Guru schrieb: > > >>Antti, >> >>I can see you are personally involved in development, that's why you >>have good info on this matter. >>The modules look VERY good (full of features), only the price bothers >>me. >>I cannot move to another platform right now, because my hardware is >>designed for Mini-Module. >>I guess I will have to implement the PPC-uClinux by myself :( >> >>Cheers, >> >>Guru > > > read what I wrote - PPC-linux (not uClinux) image is 1.3MB only > so it would work on V4MM also. > > all hydraXC-xx modules come with support DVD that includes VMWare > preconfigured environments so building a new MB-uclinux or PPC-linux > kernel for the hydraXC modules is only the matter of typing > > make > > :) > > -- there is no PPC-uclinux ASFAIK and I see no reason on even working > on it. > > Antti >Article: 105572
Hello,
I am now working with new board based on ARM processor which is
pluged on top of V4LX60 based board from avnet. But after the ARM board
is manufactured it is observed that the clock from the ARM is delayed
compared to the other signals. Since redesign of the board is not
possible i thought to advance the clock by 4ns using the DCM on the V4
board.
But the problem is the clock signal is only 10MHz frequency. Thus
it is outside the frequency range (input clock) of the DCM if i am
using the CLK0 output. Thus it is possible to use only the CLKFX
output. But the minimum output frequency is 32MHz. Thus i thought to
use two DCMs. One to multiply the input clock with 10 and will do a
phase shift of 4ns. Then this will be divided by another DCM which will
divide by 10 to get a phase advanced 10MHz frequency.
But the problem observed is that the input 10MHz and the multiplied
100Mhz are phase aligned also the input to second DCM and the output
10MHz are also aligned. The First input and the output of the second
DCM is not showing any relation ship.
How can i tackle this problem
Article: 105573When you multiply a clock and then divide it, there is no common phase relationship of the output unless you reference the original signal. I would suggest sampling the input clock using a flip-flop clocked by the 10x clock. The output of this flip-flop should have a constant (somewhat delayed) phase relationship to the original. Additional 10x clock delays can then be added to adjust the clock to the desired phase. subint wrote: > Hello, > I am now working with new board based on ARM processor which is > pluged on top of V4LX60 based board from avnet. But after the ARM board > is manufactured it is observed that the clock from the ARM is delayed > compared to the other signals. Since redesign of the board is not > possible i thought to advance the clock by 4ns using the DCM on the V4 > board. > But the problem is the clock signal is only 10MHz frequency. Thus > it is outside the frequency range (input clock) of the DCM if i am > using the CLK0 output. Thus it is possible to use only the CLKFX > output. But the minimum output frequency is 32MHz. Thus i thought to > use two DCMs. One to multiply the input clock with 10 and will do a > phase shift of 4ns. Then this will be divided by another DCM which will > divide by 10 to get a phase advanced 10MHz frequency. > But the problem observed is that the input 10MHz and the multiplied > 100Mhz are phase aligned also the input to second DCM and the output > 10MHz are also aligned. The First input and the output of the second > DCM is not showing any relation ship. > How can i tackle this problemArticle: 105574
Well I gave up on trying to find free ( and legal :-/ ) info about PCI online and ordered the mindshare PCI book. It hasn't arrived yet, but I began just writing my own PCI module. I was kinda hoping to be able to do this project w/o getting too deep into the specs of PCI, but I don't think that's going to happen. Mark McDougall wrote: > Brian McFarland wrote: > > > -- although i'm not sure how much processing it will take because our > > customers are writing the software that does it and I have no direct > > way to contanct their developers. > > In that case my response would be that I don't have sufficient detail in > the requirements to propose a solution. > > 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-3266
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