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
Gero, Why? Seems others have already progressed to the "abuse" phase, however I am curious. If microstrip, or stripline constrains the electric fields such that for all practical purposes the matched line does not radiate, why is a coaxial line any better? The only benefit of a coaxial line is that unmatched, it can not radiate (all the RF energy has to come out of the ends). Is this a concern for radiated emissions? Again, unmatched microstrip or stripline structures can be engineered with adjacent shielding such that EMI/RFI should not be an issue. Trying to create a coaxial guide by placing many vias and metal lines is just too ugly to even think about without a valid reason. Once the reason is known, the first or second approximation to the structure is probably completely adequate. AustinArticle: 115501
On Feb 10, 5:16 pm, "pete o." <port...@comcast.net> wrote: > Hopefully this won't have to be a lesson in Tcl. Here is my problem. I > am using ModelSim > with Xilinx ISE. I will make a simulation and arrange the signals in > the order I would like them. > If you hit "File" and then "Save" a box pops up asking "Save waveform > formats?" and then it lists > the path to the do file. I click OK and expect the waveform formats to > be saved, and they are not. > The reason they are not is that every time you re-run the simulation > by clicking "Simulate Behavioral > Model" an automatic do file is used and the waveforms revert to the > default order. If you highlight > "Simulate Behavioral Model" and hit "properties" there is an option to > use a custom do file. If I try > that I get to the "VSIM" prompt, but no luck after that. I assume the > "automatic" option does a > bunch of stuff for you. I'm guessing there is a command or set of > commands that will allow > you to run your simulations without making the waveform go back to the > default order. > Can someone help me with this? BTW, what if you wanted to have > multiple do files? > Would the solution be the same? > Thanks Delete all the current waveforms if they're not organized or colored as you want, then open the saved "do file" to load your format, then re-run all, Happy simulation,Article: 115502
In article <45d09f4a.260753473@news.kpnplanet.nl>,
nico@puntnl.niks (Nico Coesel) writes:
|> Programming Picoblaze in C might not be the best route for now (there
|> is no good C compiler available). However, programming the picoblaze
|> using its assembly language is quite straightforward.
While we are at it, is there any kcpsm-compatible commandline assembler for
Linux, especially for PB V3? I've found one in an KDE IDE, but that doesn't work
with makefiles. It shouldn't be too hard to write one in the lunch break, but if
it already exists...
I've tried to run kcpsm3.exe with wine, but that didn't work for some reason...
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Article: 115503On Feb 12, 12:58 pm, Magne Munkejord <Magne.Munkej...@student.uib.no> wrote: > Thanks for your reply! > > > > Sean Durkin wrote: > > Magne Munkejord wrote: > >> Hello, > > >> I have a design with several LVDS transceivers. The design works well > >> when all ports are connected but once some ports are unconnected I start > >> receiving garbage from the floating inputs. > > Well, what do you expect them to give you? If they are not connected, > > and neither pulled to ground nor to VCC, you get something in between, > > and that depends on the temperature, humidity, moon phase, your karma, > > whatever... That's why it's called "floating", because the input floats > > somewhere in between. Most of the time somewhere around the middle > > exactly where the decision threshold between 0 and 1 is, so sometimes > > you get 0, other times you get 1, which translates to garbage. > > > As the warning states, if you do attach PULLUP or PULLDOWN primitives, > > this might affect signal integrity. You might be OK with that, or it > > might screw up your data, that's for you to decide. As you know, the > > differential termination won't resolve the issue with the floating > > inputs. So, pullups/-downs might be a solution, but only if it doesn't > > affect signal integrity too much, which it seems to do in yout case > > (since you still get garbage sometimes despite of the pullups). > > Sorry, inaccurate information from my part. When I leave all ports > unconnected (no cables attached) 1 out of 8 channels still receives > garbage. When I connect cables from one port to another > data-transmission seems to be in order (2 of to 2 words received, 100% > signal integrity :) I need more statistics on this). > > >> If anyone have any suggestions on how to handle unconnected ports please > >> let me know. > > Yes, ignore everything you get from floating inputs. > > Easier said then done. The final design will have 120 serial channels. > Received data words from each channel will be stored in a shared memory > so I need to filter out the garbage words before I store them. > > > > > HTH, > > Sean > > I am well aware of the problem that a floating input acts like an > antenna. (At least I am now :) Since pullups and pulldowns are not an > ideal solution, I was hoping there might be a way to detect an > unconnected port/input and disable this channel. > I see that in my original post, I left out some vital information; The > lvds lines are used for serial data transmission over cat5 TP cables. > Non-Return-to-Zero encoding with 4 cycles per bit, 32 bit words, 2 start > bits, one parity bit and one stop bit. When the lines are idle the > transmitters should hold the lines high (when looking at the > single-ended signals from my IBUFDS/OBUFDS). > The situation now is that, if by chance, a floating input stays low for > 4 cycles and high for the 4 next, I start sampling for data bits. Of > course I can discard words with stop bit error and/or parity errors but > this method is not bullet-proof. > Maybe I should try to make a more demanding/critical start condition? I > will try to experiment a bit or two. > As you say, these are design considerations I will have to make myself. > I was thinking that this might be a common problem with a good solution > but I can't find any discussions/articles about it on the Xilinx > website. Thats why I made this thread. If anyone have some experience to > share with me I'd be grateful. It may be possible to fix this inside the FPGA if you can add a pullup to the positive input and a pulldown to the negative input of each pair. Even then, I wouldn't count on this arrangement working well due to the relatively low value of the differential termination resistor and the resulting very low voltage created by the weak pullup/pulldown pair (assuming the P&R tools really place these components). Another approach is to add external pullup/pulldown resistors to bias the signals when disconnected (also not optimal). There are LVDS receiver devices that have guaranteed outputs when the inputs are floating. They do this by sensing that the common mode input voltage is above the high limit (there is an internal pullup to create this CM voltage when the inputs float). The FPGA could do this with an additional I/O attached to one of the LVDS pair, but if you're trying to run too fast you'll have issues with the unbalanced capacitive loading. So probably the best way to avoid this mess is to use a protocol with guaranteed AC and DC characteristics like 8B-10B. You can then easily detect error conditions and disable the disconnected links. Regards, GaborArticle: 115504
"Geronimo Stempovski" <geronimo.stempovski@arcor.de> wrote in message news:45d04b34$0$27624$9b4e6d93@newsspool2.arcor-online.net... > I think transmitting high-speed signals is very easy when you have a > 360-degree ground reference, round conductors, > and no other nearby signals like in coaxial cables. My aim is to design PCB > tracks as much like a coaxial cable as > possible. Anyone tried this before? Is it possible with regular FR4, anyway? > Thanks for your help. > > Gero > Had trouble with crosstalk on a mass of video signals. Cured with a multilayer board where each signal was 'boxed in' by ground plane to the sides, above and below. Sort of square coax. -- Posted via a free Usenet account from http://www.teranews.comArticle: 115505
On 2007-02-12, Georg Acher <acher@in.tum.de> wrote: > Linux, especially for PB V3? I've found one in an KDE IDE, Pacoblaze (google it) comes with an assembler written in C++ (and source). ^ -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 115506
Hello, I am trying to debug a scenario where I am unable to upload the FPGA image from the prom to the FPGA. The image downloaded to the prom sees correct. iMPACT : 8.1.03i, Prom xcf32p, and Xilinx V Pro 100. Downloading the .mcs file via iMPACT always works. But if I bitbang the generated .xsvf file to the prom it some times does not work. Although the prom verifies okay (through iMPACT) and also the checkum of the various regions are also fine. I am using region 0 only and with compression mode enabled (the image size without compression is about 102%.). The FPGA is in slave mode and apparently the clock also seems fine. I have verified the clock both after power up(reset) and with LOAD FPGA option enabled. The Prom seems to be clocking okay (internally clocked) but apparently the data bits are all high (parallel mode). Is there a way to dump the xcf32p status registers? Any suggestions would be helpful. Thanks in advance, -KalpeshArticle: 115507
On Feb 12, 9:26 am, "Say Joe" <ngsay...@gmail.com> wrote: > I'm currently running a series of polls on Verilog, SystemVerilog, > VHDL, and SystemC. I'd like to get you guys to vote for your favorite > FPGA language use for design entry and synthesis. All poll results > will remain in public domain, and will never be used for commercial > purposes. Lame. It'll always amount to a religious war. Besides, my personal choice (Hard-C) isn't present, so I can't vote. TommyArticle: 115508
> > Lame. It'll always amount to a religious war. Besides, my personal > choice (Hard-C) isn't present, so I can't vote. No EDIF option either. Cheers, JonArticle: 115509
Hello Pablo, Pablo wrote: > Hello, I am trying to compile petalinux, but when I try to do > "petalinux-copy-autoconfig", an error appears. The problem is the > next: > > 24: function not found. > > It seems like petalinux-copy-autoconfig does not detect system.xmp. I > have tried to put explicity but not. I believe this issue is because you are attempting to use PetaLinux under Cygwin, which is not a supported environment. You may manually copy the auto-config.in file from your Cygwin installation across to the appropriate /platforms/ subdir in the PetaLinux kernel tree. It may be more appropriate to move these questions to the microblaze-uclinux mailing list - there is nothing particularly comp.arch.fpga about this stuff. Regards, JohnArticle: 115510
Sean Durkin wrote: >Magne Munkejord wrote: > > >>Hello, >> >>I have a design with several LVDS transceivers. The design works well >>when all ports are connected but once some ports are unconnected I start >>receiving garbage from the floating inputs. >> >> >Well, what do you expect them to give you? If they are not connected, >and neither pulled to ground nor to VCC, you get something in between, >and that depends on the temperature, humidity, moon phase, your karma, >whatever... That's why it's called "floating", because the input floats >somewhere in between. Most of the time somewhere around the middle >exactly where the decision threshold between 0 and 1 is, so sometimes >you get 0, other times you get 1, which translates to garbage. > >As the warning states, if you do attach PULLUP or PULLDOWN primitives, > > Xilinx's pullups/pulldowns are quite high impedance, and with the receiver terminated at low impedance, they won't change the differential voltage beyond the transition region. You'll only get a millivolt or so difference with the pullup/pulldown turned on. You will need to install EXTERNAL pullups and pulldowns of low enough resistance to pull the lines well enough away from differential zero to keep the level translator from switching. It will take at least half a mA, I think. JonArticle: 115511
On Feb 9, 7:06 am, "wojt" <wojtek.bo...@gmail.com> wrote: > Hi > > Does anyone here know, how to explicitly set which VHDL standard > should be used by Xilinx ISE (actually, by XST I think)? > > Cheers > Wojtek You don't. XST doesn't care whether it's compiling VHDL or Verilog. You can happily intermix them in the same project. G.Article: 115512
Joel Kolstad wrote: (snip) > I do remember reading how IC design generally uses lossy enough metals that > after the "lumped" approximation no longer becomes valid, switching to an RC > "transmission line" model is generally used, Not necessarily lossy, it is part of scaling. As the wires shrink in width, they also shrink in height, but often not in length. (Chips are getting larger, instead of smaller.) Resistance per unit length increases as the square of the shrinkage factor. Capacitance per unit length decreases linearly with shrinkage, so RC increases. > whereas with board-level design > usually LC is often most appropriate at first. (Eventually everything is > RLC, of course, or just true transmission lines if you have a simulator that > can deal with them -- SPICE sometimes has difficulty with lossy transmission > lines). Board metal thickness doesn't usually decrease as the wires get narrower. (Well, eventually maybe it will.) -- glenArticle: 115513
On Feb 13, 6:53 am, "Jon Beniston" <j...@beniston.com> wrote: > > Lame. It'll always amount to a religious war. Besides, my personal > > choice (Hard-C) isn't present, so I can't vote. > > No EDIF option either. > > Cheers, > Jon EDIF and Hard-C should reside under "Others", since they're not really mainstream language used.Article: 115514
Say Joe wrote: > On Feb 13, 6:53 am, "Jon Beniston" <j...@beniston.com> wrote: > >>>Lame. It'll always amount to a religious war. Besides, my personal >>>choice (Hard-C) isn't present, so I can't vote. >> >>No EDIF option either. >> >>Cheers, >>Jon > > > EDIF and Hard-C should reside under "Others", since they're not really > mainstream language used. Makes for a strange poll - just make it clear when you write this up, that you chose to severly restrict the candidate languages in the questions. -jgArticle: 115515
I found a C compiler for picoblaze, it have a manual and some examples. But i try to compile it following the direction in the manual, it was not work. It always noticed "open failes" . i also write a simple C program to test but nothing can make it run. I also try to write a email to author, but he did not answer yet. Can anyone use it and get good results? HimlamArticle: 115516
Geronimo Stempovski wrote: > I think transmitting high-speed signals is very easy when you have a > 360-degree ground reference, round conductors, > and no other nearby signals like in coaxial cables. My aim is to design PCB > tracks as much like a coaxial cable as > possible. Anyone tried this before? Is it possible with regular FR4, anyway? > Thanks for your help. > > Gero > > I would think that would be difficult and/or costly. Working from bottom to top: Start with (say) 6 mil laminate 0.5/0.5 at bottom; bottom layer has a narrow stripe to emulate the lowest part of a coax, and top part is a wider stripe: both ground (shield). Next layer (#2) is (say) 6 mil laminate 0/0.5 (ie bottom has no copper and top is 0.5 ounce); stripe is wider and is ground. "Middle" or next layer is (say) 6 mil laminate 0/0.5 (ie bottom has no copper and top is 0.5 ounce); 3 stripes: ground / center conductor / ground. Next layer is (say) 6 mil laminate 0/0.5 (ie bottom has no copper and top is 0.5 ounce); stripe is as wide as layer #2. Then use (say) 6 mil laminate 0/0.5 at top; where the top copper has a "wide" stripe same as first laminate top stripe as ground. Finish with (say) 6 mil laminate 0/0.5 at top; where the top copper has a "narrow" stripe same as first laminate bottom stripe as ground. Use more layers if they are thinner. Use vias liberally for tying the ground stripes together. Note the 6 mils is a wild guess.Article: 115517
John Fields wrote: > On Mon, 12 Feb 2007 12:10:43 +0100, "Geronimo Stempovski" > <geronimo.stempovski@arcor.de> wrote: > > >>I think transmitting high-speed signals is very easy when you have a >>360-degree ground reference, round conductors, >>and no other nearby signals like in coaxial cables. My aim is to design PCB >>tracks as much like a coaxial cable as >>possible. Anyone tried this before? Is it possible with regular FR4, anyway? >>Thanks for your help. > > > --- > http://en.wikipedia.org/wiki/Microstrip > > He said "coax"...Article: 115518
Fred Bloggs wrote: > >> I think transmitting high-speed signals is very easy when you have a >> 360-degree ground reference, round conductors, >> and no other nearby signals like in coaxial cables. My aim is to >> design PCB tracks as much like a coaxial cable as >> possible. Anyone tried this before? > > > Nope- in all the decades of high speed PC circuit design, you are the > first to think of it! > >> Is it possible with regular FR4, anyway? > > > Not even close, the "phase velocity," or speed to you, will be less than > that of free space by a factor of 1/sqrt(epsilon-sub-r), so go figure. > > Gee, coax cables, even those that use spiral teflon seperators, are like that...Article: 115519
Robert Baer wrote:
> John Fields wrote:
>> <geronimo.stempovski@arcor.de> wrote:
>>
>>> I think transmitting high-speed signals is very easy when you
>>> have a 360-degree ground reference, round conductors, and no
>>> other nearby signals like in coaxial cables. My aim is to design
>>> PCB tracks as much like a coaxial cable as possible. Anyone
>>> tried this before? Is it possible with regular FR4, anyway?
>>
>> http://en.wikipedia.org/wiki/Microstrip
>>
> He said "coax"...
Which is just one more way of implementing a line. As is a piece
of wire in some medium.
Ridiculous cross-post level reduced by setting follow-ups.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Article: 115520
On Feb 12, 2:30 pm, "john jardine" <j...@jjdesigns.fsnet.co.uk> wrote:
> "Geronimo Stempovski" <geronimo.stempov...@arcor.de> wrote in message
>
> news:45d04b34$0$27624$9b4e6d93@newsspool2.arcor-online.net...> I think transmitting high-speed signals is very easy when you have a
> > 360-degree ground reference, round conductors,
> > and no other nearby signals like in coaxial cables. My aim is to design
> PCB
> > tracks as much like a coaxial cable as
> > possible. Anyone tried this before? Is it possible with regular FR4,
> anyway?
> > Thanks for your help.
>
> > Gero
>
> Had trouble with crosstalk on a mass of video signals. Cured with a
> multilayer board where each signal was 'boxed in' by ground plane to the
> sides, above and below. Sort of square coax.
>
> --
> Posted via a free Usenet account fromhttp://www.teranews.com
----------------------------------------------------------
Boxed ! the wavelength is far greater than
your dimensions , thus higher modes can not
exist , thus you do NOT need sides .
When you reach 10 Ghz , then maybe
you need sides in ur boxed "coax" .
But the big joke , is in the real world ,
they use cheap PCB to xmit 2.5 Ghz .
No strip line , no microstrip , nada ..
It works well , so quit arguing reality .
BTW , i saw some novice , trying to
use juice cans to launch WiFi .
He figured the more cans , the more
gain . He had 3 cans , T'd .
to divide the power .
Gain is not in cans , its in size of
the dish .
Another book worm said all i needed
was $26 for 100 meters of blah blah
coax at 2.5 Ghz ..
10 times that price !
and 1.8" dia hard line !
At these wavelengths , its lower loss
to send it TEM and thru the air ,
not thru a coax .
This is goin to FPGA ? Do those relics
still exist ?! Oh well , i supose ya gotta
try to "protect" your firmware by reinventing
the CPU !
Article: 115521"John Fields" <jfields@austininstruments.com> wrote in message news:aab1t2dlh31fogqb48o6uptri6qr4at2ml@4ax.com... > On Mon, 12 Feb 2007 14:39:30 +0100, "Geronimo Stempovski" > <geronimo.stempovski@arcor.de> wrote: > >> >>"John Fields" <jfields@austininstruments.com> schrieb im Newsbeitrag >>news:urq0t2533bdm5e2t2ui82b7fo8ppvsbqs8@4ax.com... >>> >>> http://en.wikipedia.org/wiki/Microstrip >>> >> >>Microstrip has absolutely nothing to do with the coaxial structure I had >>in >>mind. > > --- > Well, Mister Nasty-Ass, what exactly did you have in mind, then? > > > -- > JF How DARE you not know what he had in mind! BobArticle: 115522
Thuy Pham wrote: > Hi everyone, > > I am working on my brother's school project to develop a STM-16 framer > in FPGA but I have no idea about SONET so I am really appreciated if you > can give me some instruction or idea to do it. There is also one > question for the project "What are the main functions and how do you > test it ?" Just get the ITU-T G.707 document first and read it trough. It is quite well written and about 180 pages long. I'd say it is impossible to develop a STM-x framer without reading the basic standard about the frame structure. If you need to process error conditions, pointers etc. G.783 might be a good starting point (~300 pages). --KimArticle: 115523
fpgabuilder schrieb: > On Feb 12, 4:31 am, backhus <n...@nirgends.xyz> wrote: >> Hi CMOS, >> here's the solution you want: >> >> Assume the two input matrices to be stored in two separate RAMs (e.G. >> Blockrams). Dual Ported, if necessary. >> >> Connect a subtractor circuit to the DataOut of these RAMs. >> The Output of that circuit is identical to the output of your Result-RAM >> >> Now the result is virtually existent. If anyone has a doubt, just make a >> readout of the Result-RAM. The result will be there. :-) >> >> Have a nice synthesis >> Eilert > > Are you saying that the above mechanism will compute a difference of > two arrays in one clock cycle? If so then, I am not following... > maybe you can explain a bit more. > Hi fpgabuilder, the above circuit is even faster, it needs no extra Clock cycle. The point is, that CMOS didn't mention how the data is written to the RAM and how the result will be read out. Show me the RAM that can be written or read in a bulk, that is "all data at once". There is no such device. So what my circuit does is that it presents a Result-Databus over which the subtraction result of RAM1 and RAM2 can be read out. So the results are virtually existent in that "Result-RAM" instantly after writing the last word of data into the Input-Rams. All you need to do is read them out. If one uses DP-RAMS as mentioned the results can even be read out while the Data is written to the input rams. Even more... If you can manage your Dataflow in a way, that the first results are read out one clock cycle after the two input values have been written you can use time multiplexing mechanisms to reduce the ram size. In fact the RAMs collapse into single registers and are capable of storing arrays of any size, just one value at a time. But it works. I know, it sounds kind of tricky, but a lot of designers are using circuits like this. Have a nice synthesis EilertArticle: 115524
Himlam8484 schrieb: > I found a C compiler for picoblaze, it have a manual and some > examples. But i try to compile it following the direction in the > manual, it was not work. It always noticed "open failes" . i also > write a simple C program to test but nothing can make it run. > > I also try to write a email to author, but he did not answer yet. Can > anyone use it and get good results? > > > Himlam > Hi Himlam, let me set some points straight. 1.) There "is" no PicoBlaze processor into any FPGA unless you have synthesized the PicoBlaze sources (and the rest of your design) and downloaded the bitstream into the FPGA. 2.) As far as I know there is only one C-Compiler available for the PicoBlaze: PCCOMP from Francesco Poderico. This one supports only Picoblaze for Spartan3 and Virtex II FPGAs. So, which kind of FPGA are u using on your board? Which "open fails"? The open for reading your source code or have you used an open() function in your source? In the first case you probably made some mistake while invoking the compiler. In the second case you just forgot that you are writing code for a simple microcontroller. There is nothing to open. Have a look at the manual. The allowed statements are as reduced as the PicoBlaze itself is. So take good care what you are programming. Not everything is allowed or meaningful when using PCCOMP. About the other questions: You can run the KCPSM.EXE under linux by using some DOS emulation program. I'm running it under wine : wine kcpsm.exe <infile.psm> I'm not sure about the KCPSM3.EXE. Either your WINE is not up to date, or maybe you forgot to put the ROM_form.* templates into the correct path? Have a nice synthesis Eilert
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