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
Hi,
I know this is a bad hack, but just disable the Xilinx INT
controller for now and then compile the kernel. After compiling the
kernel, please try downloading... I guess doing this way would atleast
narrow down the problem...
--
Parag
Article: 99801Art Stamness wrote: <snip> > My simple assertion is that the added layer of indirection provided by > the "my_dff" construct, and the seperate wire containing the result, > gives me things easily, that would require RTL changes in the above > example. > > Lets say I want to simulate my design and initialize all registers to a > non-X state, just for simulations, just to see what would happen. I > would swap in a different my_dff with the attribute that I want, it > would change my compile script, but not my source code. > Yes, I agree with you that it is easy to do this particular transformation with your style. However, it's not enough to convince me, as this transformation can also be easily done with the proper RTL style, if not easier. With one or two lines of regular expression code/shell script, I can mine through the entire source code and generate a big initial block, which I conveniently insert in the testbench. To me, portability is greater with more abstraction in the code, because it gives synthesis tools greater freedom to implement the logic.Article: 99802
Hello, I'm having great difficulty interfacing my FSL to my external (from microblaze point of view) VHDL. I want an FSL to communicate between Microblaze and my external VHDL. I want to be able to import the .xmp file to my ISE project and then create the instantiation template (wrapper) for the XMP file (*_stub.vhd). In the file I need to see the FSL control signals, data etc. I cannot get this to happen. I'm thinking there needs to be some kind of interface VHDL inside of the EDK project and then make those signals external. Please offer any help you can. I'm frustrated.... at the end of my rope :). Thanks, DaleArticle: 99803
Davy wrote: > Hi all, > > After I use Xilinx ISE do Place & Round and generate bit file, I am > confused with a DRC warning=E3=80=82 > > "WARNING: DesignRules:7-Netcheck: An antenna was found on signal; this > means that a branch of this signal is partially routed or has a routing > stub". > > I found bit file with this DRC warning cannot work properly. > > But what's this signal connected to? A tri-state bus? Or this signal > wire form a loop? > > Any suggestions will be appreciated! > Best regards, > Davy You have to go back and look at the place & route report. I'm surprised that this is a warning and not an error. It sounds like the router didn't complete...Article: 99804
Thanks mate, i did fill the form for the trial version. let see how its gonna go !! cheers !!!Article: 99805
Andy wrote: > +1 for natural type on phase_ctr! > > Inside a process (sequential statements): > > phase <= (others => '0'); -- sequential statements > phase(phase_ctr) <= '1'; > > Or if phase is a natural too: > > phase <= 2**phase_ctr; -- sequential or concurrent assignment > > Andy Doh! This is great. (Sometimes I scare myself by how I miss the simplest things). Thanks Andy. Any more examples of keystroke/eye/paper savers out there?Article: 99806
Austin Lesea schrieb: > take a 20.000 MHz oscillator and generate exactly the 8 MHz reference > you need. I used for the 2E clocks, the raw rubidium output, which was > 50.2037(etc) MHz (basically every rubidium is shlightly different, but > they don't drift very much <1E-12, and some don't drift at all! - tested > them for 8 months with less than 1E-14 drift...). > > The tracking algorithm needs some thought. The phase detctor needs some > thought. The reasons to stop tracking needs a lot of though. The > reasons to start tracking again also needs thought. > Depending on how you implement your loop, there is a patent on the way I > did it (uspto.gov, search on - Austin, Lesea, as inventor, and look for Maybe a ASSP is an easier solution. Zarlink (formerly Mitel) & Co are your friends. Plug & Play. MFG FalkArticle: 99807
Hi Dumak, Zara was right (thank you :)). I found .cdc file at the "implementation\chipscope_opb_iba_0_wrapper". It helps a lot. Thnx, GuruArticle: 99808
Thanks Derek. Yeah, I haven't come across a multithreaded version of the NIOS II so far. I was curious to know if a multithreaded NIOS is under development. Since NIOS is an Altera core, I think a multithreaded NIOS might be designed bottom-up more appropriately for an FPGA implementation compared to other multithreaded cores. Will check out the niosforum website and see if I can find any additional information there. Yeah, I have also been looking at the OpenSPARC. Looks promising. Haven't managed to synthesize it yet because our DC environment here is not appropriately set up. I think some implementation decisions would probably have to be different for an efficient FPGA mapping. Also guess some of the Verilog would have to be modified in order to take advantage of the available FPGA architecture. Thanks again, Shyam Derek Simmons wrote: > I can't speak for Altera but I haven't heard anything about a > multithreaded/hyperthreaded NIOS core. It might be better if you asked > you question at the www.niosforum.com website. > > Have you check Sun's website for the OpenSPARC project? I think it > supports multiple cores and hyperthreading. > > Technology-wise it might still might be a little early to find a lot of > projects or examples. > > DerekArticle: 99809
Hi Michiel,
To correctly use a tristate you need 3 ports in your peripheral design
(VHDL)
for a single port ("port") in MPD and UCF file:
port_I port Input
port_O port Output
port_T port Toggle (low (0) enables you to write to tristate)
and in MPD: PORT port = "", DIR = INOUT, ENABLE=SINGLE,
THREE_STATE=TRUE
in UCF: NET port LOC = xx;
I hope this helps.
Guru
Article: 99810Falk, Very good point! Also check out ICS. Austin Falk Brunner wrote: > Austin Lesea schrieb: > > >> take a 20.000 MHz oscillator and generate exactly the 8 MHz reference >> you need. I used for the 2E clocks, the raw rubidium output, which >> was 50.2037(etc) MHz (basically every rubidium is shlightly different, >> but they don't drift very much <1E-12, and some don't drift at all! - >> tested them for 8 months with less than 1E-14 drift...). >> >> The tracking algorithm needs some thought. The phase detctor needs >> some thought. The reasons to stop tracking needs a lot of though. >> The reasons to start tracking again also needs thought. > > >> Depending on how you implement your loop, there is a patent on the way >> I did it (uspto.gov, search on - Austin, Lesea, as inventor, and look for > > > Maybe a ASSP is an easier solution. Zarlink (formerly Mitel) & Co are > your friends. > Plug & Play. > > MFG > FalkArticle: 99811
Art Stamness wrote: >>Again, I don't see how writing always blocks is "unmaintainable." Maybe I haven't had enough experience > > > Let met explain then. Here is the "proper RTL" as some other might > right it : > > wire [31:0] a ; > wire [31:0] b ; > reg [32:0] result ; > always @(posedge clk) result <= a + b ; > > Here is what you will find in many high end synthesizable RTL coding > standard examples : > > wire[31:0] a ; > wire[31:0] b ; > wire[32:0] a_plus_b ; > > assign a_plus_b = a + b ; > > my_dff #(33) a_plus_b_32_0 ( .out( result ), .clk(clk), .in(a_plus_b) ) > ; > > And here is what we use in our coding standard wire [31:0] a; wire [31:0] b; reg [32:0] result; reg [32:0] next_result; always@(*) begin next_result = a + b ; end always@(posedge clk) result[32:0] <= next_result[32:0]; This seperates the sequential from the combinational logic without impacting the ability to understand the function. Plus it can be processed so we can do things like switch between sync and async resets or add a clock enable signal to all flops. Hand crafting rtl code is going the way of schematic capture. Yes, it gives you complete control of every last detail in your design but chips have grown to the point where you don't have the time to deal with all that detail in a normal product cycle. You have to use more automated methodogies if you plan on finishing in a reasonable time. John EatonArticle: 99812
and, IDT also has products. Hard to beat when it is all done for you, and costs only ~$20 for the ASSP. Austin Austin Lesea wrote: > Falk, > > Very good point! > > Also check out ICS. > > Austin > > Falk Brunner wrote: > >> Austin Lesea schrieb: >> >> >>> take a 20.000 MHz oscillator and generate exactly the 8 MHz reference >>> you need. I used for the 2E clocks, the raw rubidium output, which >>> was 50.2037(etc) MHz (basically every rubidium is shlightly >>> different, but they don't drift very much <1E-12, and some don't >>> drift at all! - tested them for 8 months with less than 1E-14 drift...). >>> >>> The tracking algorithm needs some thought. The phase detctor needs >>> some thought. The reasons to stop tracking needs a lot of though. >>> The reasons to start tracking again also needs thought. >> >> >> >>> Depending on how you implement your loop, there is a patent on the >>> way I did it (uspto.gov, search on - Austin, Lesea, as inventor, and >>> look for >> >> >> >> Maybe a ASSP is an easier solution. Zarlink (formerly Mitel) & Co are >> your friends. >> Plug & Play. >> >> MFG >> FalkArticle: 99813
Falk, I know the Zarlink parts, but I already have the FPGA for other functions. So I want to use it. Thanks anyway. Austin, First, thankyou very much. I was looking "Frequency Synthesis" by Austin Lesea (what a coincidence, do You know him?) at Xcell 31. I didn't understand how can I have a jitter reduction, synthetising a higher frequency and then, dividing it down. The jitter will be the period of the incoming clock, isn't it? Now, let's say I have a 50MHz very stable clock. Using DDFS, I generate a 8.192MHz clock. The size of the adder (number of bits) will be related to the precision desired, but will not be related to the jitter. The jitter, will be 20ns (1/50MHz). To get a better jitter I can: a) use one DCM at the input clock to generate a higher input clock (N*50MHz), b) use one DCM (the DLL part) at the output clock to filter it (I'm not sure about this). Can you comment on this? Luiz CarlosArticle: 99814
Precisely, anyone who has done FPGA cpu design knows how limiting FPGAs can be .ie 20-120MHz is typical for unfriendly architectures. If your not in that very small club of Intel, AMD, IBM, then even full custom is also pretty limiting by the extreme expense of it all. The top tier may still be directly instantiating transistors as well as flops. But then transistor level design is still able to significantly outperform standard cell logic using a variety of mostly nmos differential techniques, I guess by a factor of 3. At Suns level, they are much closer to full standard cell with synthesis with a fraction of the clock of P4s but they make up for it by going to massive threading and latency hiding to bring out the throughput. Theres the clue there. The same can be done in FPGA cpu for multithreading architecture to simplify the design so that you are not limited to 32b carry ripples. In my Transputer design I was seeing 300MHz on the PEs because it could use 2 clocks per basic opcode and used 8 clocks for 4 thread instructions, alot of cycle limiting logic just vanishes, ie no hazard logic or register forwarding paths. The hardware design of the MMU hasn't started so there is nothing to release. For information, my PE used 500 LUTs & 1 BlockRam and a few hundred LOC in RTL Verilog. Given V4 can hold upto 554 BlockRams, means I coudl instance quite a few of these PEs too. In some ways it is quite similar similar to the Niagara/Sparc, whats the difference between slidy register files with stack spilling v register files in memory but cached on demand (process swapped) into register caches as the T9000 did. If I wanted to see a Niagara core in FPGA I think I would go back to the Sparc architecture documents and maybe LEON and see if a threaded design could be done from scratch that executes the ISA but possibly make some very different choices so the FPGA version wouldn't get crippled. I wouldn't be constrained to 1 opcode per clock either, using more clocks, lowers PE performance by clock but allows a much faster clock and much less logic so more PE cores. I am surprised that we haven't seen alot more native FPGA MTA designs though,. John Jakson Transputer guyArticle: 99815
Sure, The 20 ns will be there (in your example) and the only way to remove it is to filter it out. Filters come in two forms: a PLL, and also one can use a LC tank (with a Q>100). The LC tank is very analog, but works great. It is what I used: MSB of DDFS into a 100K resistor into the LC tank, followed by a fast comparator. Residual jitter was less than 1% from 10 Hz up. A PLL with a long time constant is also very good. I made them with VCXO's, an RC network to the voltage control, and a XOR phase detector. Austin oen_no_spam@yahoo.com.br wrote: > Falk, > I know the Zarlink parts, but I already have the FPGA for other > functions. So I want to use it. Thanks anyway. > > Austin, > First, thankyou very much. > > I was looking "Frequency Synthesis" by Austin Lesea (what a > coincidence, do You know him?) at Xcell 31. > I didn't understand how can I have a jitter reduction, synthetising a > higher frequency and then, dividing it down. The jitter will be the > period of the incoming clock, isn't it? > Now, let's say I have a 50MHz very stable clock. Using DDFS, I generate > a 8.192MHz clock. The size of the adder (number of bits) will be > related to the precision desired, but will not be related to the > jitter. The jitter, will be 20ns (1/50MHz). > To get a better jitter I can: > a) use one DCM at the input clock to generate a higher input clock > (N*50MHz), > b) use one DCM (the DLL part) at the output clock to filter it (I'm not > sure about this). > > Can you comment on this? > > Luiz Carlos >Article: 99816
I would have to disagree about hand crafted code going away. I believe Intel, IBM, Sun, AMD, Cisco, and even HP, all still use RTL based hand coded design methodologies for most all of their designs, that I am aware of. IP reusage models cut down on the actual number of lines of code written by leveraging pre-built high level libraries, with fifo's, memories, register files, and other constructs. Soc vendors are also doing less and less design, as more of the code they actually produce comes in the form of pre-verified IP, and their job is moved to verification of the integrated system from verification of the individual components. I don't see however "whats next", as far as getting us away from hand written code. We can save time by buying others hand written code, but what other tools are you aware of that would take the place of Verilog ?? -ArtArticle: 99817
Hi I have test it and got this error ERROR:MDT - test_I (IO_0) - D:\Thesis\Test\XPS_versie8\IO\system.mhs line 358 - port is driven by a sourceless connector this is what I have done first I added this in the vhdl test_I : in std_logic_vector (7 downto 0); test_O : out std_logic_vector (7 downto 0); test_T : out std_logic_vector (7 downto 0); and this s_test <= test_I; test_O <= s_test; test_T <= "00001111"; then I have added this in the MPD file PORT test = "", DIR = INOUT, ENABLE=SINGLE, THREE_STATE=TRUE, VEC = [7:0] PORT test_I = "", DIR = IN, VEC = [7:0] PORT test_O = "", DIR = OUT, VEC = [7:0] PORT test_T = "", DIR = OUT, VEC = [7:0] and this in the ucf file Net IO_0_test_pin Loc = "N6"; Net IO_0_test_pin IOSTANDARD = LVTTL; then I get this error ERROR:MDT - test_I (IO_0) - D:\Thesis\Test\XPS_versie8\IO\system.mhs line 358 - port is driven by a sourceless connector there must be something I missed can you tell me what it is? Greets MichArticle: 99818
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:i88l229so8qheephlt41crc0v7e5ebch3r@4ax.com... > On 29 Mar 2006 01:00:59 -0800, bill.sloman@ieee.org wrote: > >> >>John Larkin wrote: >>> On 28 Mar 2006 12:45:23 -0800, bill.sloman@ieee.org wrote: >>> >>> >>> >So the Fpga to Fpga routing worked - good. >>> >>> That's not what we did. We designed a clock deglitcher to go inside >>> the FPGA. >> >>Enough propagation delays to cover the dwell at the switching >>threshold, and a state machine to make sure that the clock only changes >>state once in that interval? > > > We did my original #2 suggestion, a tapped delay line driven from the > pin, driving an r-s flipflop. Set the flop if all the taps are 1s, > clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter. > The delay line is a string of eight buffers, about 10 ns overall. > > We'd have done Peter's circuit if we'd learned of it sooner. > > It's interesting that my post evoked two classes of response: > > 1. It can't be done, don't do it, kluge the boards (also the official > Xilinx response!) > > 2. Yes, and here are my ideas on how you could do it/how I've already > done it/interesting asides. > > John > > 'We tried that before and it didn't work' 'OK, what did you try before' 'He was very good and proved it didn't work with some maths type stuff and it didn't work' 'Yes, but what did he try' 'It didn't work' 'But, what was it' 'It didn't work' 'Have you got the information about it' 'Err, no, err hang on.' Waits a while. Mouldy thing arrives. 'There you go, see doesn't work' 'OK, let me have a look' Goes away for a bit of..... Comes back 'So, the problem is he did it like this' 'Doesn't work' 'Yes... but if you do it like this' Spends some time explaining.... 'He was very clever, see... here's the math, it doesn't work. We've tried it before and it doesn't work' 'OK, but if you do it like this then it will work' 'No, we've already tried it and it doesn't work' 'You've tried it the way that I'm suggesting' 'Pardon' 'This way' 'Erm, he was very clever. Look, if you take some time then you can see that it doesn't work... How did you answer the 'Where do you see yourself in five years time' question at the interviev?' DNAArticle: 99819
oen_no_spam@yahoo.com.br schrieb: > Falk, > I know the Zarlink parts, but I already have the FPGA for other > functions. So I want to use it. Thanks anyway. I see. And I know that you like the challenge. But from a economic point of view its a matter of part cost (Austin quoted 20 $) versus developlment (and verification) time. And its not done in an hour if you did'nt do it before and are a 100% pro in this sector. > To get a better jitter I can: > a) use one DCM at the input clock to generate a higher input clock > (N*50MHz), Yes. > b) use one DCM (the DLL part) at the output clock to filter it (I'm not > sure about this). Nope. Regards FalkArticle: 99820
"Genome" <ilike_spam@yahoo.co.uk> a écrit dans le message de news:sLCWf.25632$Nh7.15570@newsfe4-win.ntli.net... > > "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message > news:i88l229so8qheephlt41crc0v7e5ebch3r@4ax.com... > > On 29 Mar 2006 01:00:59 -0800, bill.sloman@ieee.org wrote: > > > >> > >>John Larkin wrote: > >>> On 28 Mar 2006 12:45:23 -0800, bill.sloman@ieee.org wrote: > >>> > >>> > >>> >So the Fpga to Fpga routing worked - good. > >>> > >>> That's not what we did. We designed a clock deglitcher to go inside > >>> the FPGA. > >> > >>Enough propagation delays to cover the dwell at the switching > >>threshold, and a state machine to make sure that the clock only changes > >>state once in that interval? > > > > > > We did my original #2 suggestion, a tapped delay line driven from the > > pin, driving an r-s flipflop. Set the flop if all the taps are 1s, > > clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter. > > The delay line is a string of eight buffers, about 10 ns overall. > > > > We'd have done Peter's circuit if we'd learned of it sooner. > > > > It's interesting that my post evoked two classes of response: > > > > 1. It can't be done, don't do it, kluge the boards (also the official > > Xilinx response!) > > > > 2. Yes, and here are my ideas on how you could do it/how I've already > > done it/interesting asides. > > > > John > > > > > > 'We tried that before and it didn't work' > > 'OK, what did you try before' > > 'He was very good and proved it didn't work with some maths type stuff and > it didn't work' > > 'Yes, but what did he try' > > 'It didn't work' > > 'But, what was it' > > 'It didn't work' > > 'Have you got the information about it' > > 'Err, no, err hang on.' > > Waits a while. Mouldy thing arrives. > > 'There you go, see doesn't work' > > 'OK, let me have a look' > > Goes away for a bit of..... > > Comes back > > 'So, the problem is he did it like this' > > 'Doesn't work' > > 'Yes... but if you do it like this' Spends some time explaining.... > > 'He was very clever, see... here's the math, it doesn't work. We've tried it > before and it doesn't work' > > 'OK, but if you do it like this then it will work' > > 'No, we've already tried it and it doesn't work' > > 'You've tried it the way that I'm suggesting' > > 'Pardon' > > 'This way' > > 'Erm, he was very clever. Look, if you take some time then you can see that > it doesn't work... How did you answer the 'Where do you see yourself in five > years time' question at the interviev?' > ROFL. - OK, but I don't understand why it can't work. Please let me try and learn by myself why it can't. ... ... - Oh, but you made it work. How can it be? - Oh. That's pretty simple: I just didn't know it couldn't work :-) -- Thanks, Fred.Article: 99821
Fred Bartoli schrieb: > ROFL. Yep. But try better quoting. > > - OK, but I don't understand why it can't work. Please let me try and learn > by myself why it can't. > ... > ... > - Oh, but you made it work. How can it be? > - Oh. That's pretty simple: I just didn't know it couldn't work :-) I just saw a nice TV show, which ended with the words. Theory is the thing you can't understand. Practice is the thing you can't explain. Regards FalkArticle: 99822
Hi Dale, dale.prather@gmail.com wrote: > I'm having great difficulty interfacing my FSL to my external (from > microblaze point of view) VHDL. I want an FSL to communicate between > Microblaze and my external VHDL. I want to be able to import the .xmp > file to my ISE project and then create the instantiation template > (wrapper) for the XMP file (*_stub.vhd). In the file I need to see the > FSL control signals, data etc. I cannot get this to happen. I'm > thinking there needs to be some kind of interface VHDL inside of the > EDK project and then make those signals external. Please offer any > help you can. I'm frustrated.... at the end of my rope :). You'll probably need to create explicit FSL signals and bring these out as toplevel ports in the EDK / MicroBlaze design. And at the top of the MHS file, you'll have typical port declarations PORT FSL0_S_CLK = fsl0_s_clk, DIR = O PORT FSL0_S_DATA = fsl0_s_data, DIR = I PORT FSL0_S_CONTROL = fsl0_s_control, DIR = I PORT FSL0_S_EXISTS = fsl0_s_exists, DIR = I PORT FSL0_S_READ = fsl0_s_read, DIR =O then later begin microblaze ... PARAMETER C_FSL_LINKS=1 ... PORT FSL0_S_CLK = fsl0_s_clk PORT FSL0_S_DATA = fsl0_s_data PORT FSL0_S_CONTROL = fsl0_s_control PORT FSL0_S_EXISTS = fsl0_s_exists PORT FSL0_S_READ = fsl0_s_read ... end This is for a microblaze slave (incoming) port, it will be a little different for outgoing ports, but the idea should be the same. Does that hlep ? JohnArticle: 99823
Art Stamness wrote: > I would have to disagree about hand crafted code going away. > > I believe Intel, IBM, Sun, AMD, Cisco, and even HP, all still use RTL > based hand coded design methodologies for most all of their designs, > that I am aware of. Yes there is a lot of legacy code out there and a lot of design houses are still hand coding more. They are also finding it harder and harder to support this code as chips grow and processes shrink. You start finding teams that are afraid to touch blocks that have been proven in silicon for fear of introducing bugs. One of our standard practices is to put in a new component but leave in the old version and give firmware the ability to select which one is used at run time. > > IP reusage models cut down on the actual number of lines of code > written by leveraging pre-built high level libraries, with fifo's, > memories, register files, and other constructs. Soc vendors are also > doing less and less design, as more of the code they actually produce > comes in the form of pre-verified IP, and their job is moved to > verification of the integrated system from verification of the > individual components. > > I don't see however "whats next", as far as getting us away from hand > written code. We can save time by buying others hand written code, but > what other tools are you aware of that would take the place of Verilog > ?? > Creating the design is 20% of the effort. Verification is the other 80%. The industry is heading toward systems where you can specify the desired behaviour and create the design and the testbench at the same time from the same source. This goes well beyond providing a richer assortment of register files. We are advancing from "assemblers" into "compilers" But thats only the start. You want to design a component once and reuse it over and over again. Each user should be able to reconfigure your component's parameters for their exact needs and your tool set must be able to rebuild both the rtl code and the testbench for these new parameters. Futhermore the user will want to use this newly configured component as a building block of another component in their chip. The tool set must be able to "Plug&Play" the rtl code into the chip. This also involves building a chip level testbench and documentation from all of the included components in a fast and efficient manner. Each stage should be able to verify that everything below it still works and you can't spend weeks of engineering time fixing sims and hand placing components to reach that point. The methodologies must be able to handle it. John Eaton > -Art >Article: 99824
=ABDigital integrated circuits.a design perspective(Second
Edition)=BB
Author:Jan.M.Rabaey
My teach tell me this is a very good book.But now,I am a fresh
person in this field.My mostly work is write verilog code everyday.And
before I studying verilog,micron-electronic is not my major.When I was
a undergraduate student,my major is Elecronic and Infmation
Engneer.So,now,read this book is very hard for me.I also puzzled about
the relation ship between this book and RTL design.
Please help me,thanks!
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