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
"Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1138164692.600244.310200@g14g2000cwa.googlegroups.com... > The circuit is reliable, although the generated pulse width is > determined by gate delays. But it is self-compensating, since the clock > pulse will not end until the flip-flop has toggled. It's kind of > clever, if I am allowed to say so... > Peter Alfke > *blush* gee thanks, I first put forward this idea in 1973 to a UK electronics mag, I believe I received about £150 for the article way back then! SlurpArticle: 95651
When 71i came out, I requested Xilinx, via google groups, to reconsider the download management strategy. Unfortunately it was not acknowledged. When trying to download 81i, I noticed that support is only through xilinx web site. I contacted Xilinx support via web today, and hope to hear from them soon!Article: 95652
hi,
I would like to implement a secure channel over an unsecure medium.
mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A
conv =>voice
analog Host A/D digital
"other side"
I do not want to encrypt data at the device's digital side
because it is unsecure, and I dont know how to interfere digital data
I don not have access to embedded software, source code etc.
(maybe just after host A/D converter and emulating Host A/D converter
to device,,,maybe) and
every encryption algorithm implemented here can be broken at the other
side I guess.
What I want to do is ;
mic(voice) => A/D conv + cpld or fpga + D/A conv =>A/D conv => unknown
comm link
analog ecrypt + scramble digital data voice like
encrypted signal
The Device will see voice freq signal and will transmit them through
channel as if they are real voices.
At this point adding some noise may help a lot.
a little bit noise may fool attackers but human still can understand
what is said.
questions:
what is possible weakness of this system?
I am sure it can be still broken but
how easy to break it?
What kind of tools/approaches "they" are using ?
Is cpld enough for general data encryption?
(data is human voice so 8Kbps.)
encrytion should be easy so the hacking also....
they: whatever you say
thanks
yusuf
Article: 95653In another thread we've been talking about creating some open source tools for parsing and manipulating XDL. The motivation being that since bitstreams are closed, working XDL might just be the next best thing. But then someone brought up the fate of JHDLBits: apparently the prjoject was squashed by Xilinx. Does anyone have any details about what happened? If someone succeeded in developing an open source ecosystem of tools built around XDL, would that project also suffer the same fate? (It would be nice to know before investing much time and effort in developing tools around XDL) I found a Master's thesis related to JHDLBits and it sounds eerily similar to the motivation for developing XDL tools, here's the title and abstract: JHDLBits: An Open-Source Model for FPGA Design Automation Alexandra Vanessa Poetter Abstract Todays Field Programmable Gate Array (FPGA) research community could use an extensi- ble tool flow enabling designers to examine new algorithms and new methods of interacting with FPGA configurations. One such flow is JHDLBits, which integrates two prominent FPGA design environments: JHDL and JBits. JHDLBits offers the low-level access and control provided by JBits with the high-level structural circuit design of JHDL. Further- more, the JHDLBits flow provides greater control of resource manipulation, placement, and routing, and gives researchers a sandbox to explore advanced interactions with FPGA config- urations. This thesis presents the overall architecture of the open-source JHDLBits pro ject. Details are provided on how the core components JHDL, JBits3 for Virtex-II, the ADB connectivity database, and VTsim, a Virtex-II device simulator are linked together to provide an integrated design environment. Strategies and philosophies of the open source movement are also examined to successfully establish the support for and involvement of the FPGA research community throughout the JHDLBits open source endeavor. The thesis can be found here: http://rubyurl.com/wvm PhilArticle: 95654
Thanks I have done some work using this circuit and it seems to function well. Since the clk is 640Khz, the requirement of clk_min should be satisfied. I have another two aspects: *the width of pulses generated by this circuit, and *the delay caused by this circuit whether these two are safe when implementing the design by asic tech? As a learner with little experience, every reply give me great help and will be highly appreciated.Article: 95655
Thanks for putting forward so good a circuit, which is one of the most wonderful design I have ever learned!Article: 95656
"Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1138164692.601427.310190@g14g2000cwa.googlegroups.com... > The circuit is reliable, although the generated pulse width is > determined by gate delays. But it is self-compensating, since the clock > pulse will not end until the flip-flop has toggled. It's kind of > clever, if I am allowed to say so... > Peter Alfke > Hi Peter, Clever the circuit may be, but I'm concerned that it may not be a good idea to suggest this circuit to a guy who appears to be just starting out using FPGAs. I agree it's a quick and easy answer to get him going, but he should be made aware of the pitfalls of this circuit. For one, how will the timing analyser cope with this? Also, how does he control the skew between input and output? In your article you rightly say "This asynchronous circuit ... should only be used as a tool of last resort.", so it should be in CAF threads as well! I'd strongly suggest the OP use a DCM or PLL or whatever his FPGA vendor supplies to double his clock. He should wait until he's really desperate before resorting to asynchronous tricks, no matter how clever they are! Just IMHO! Cheers, Syms. p.s. If the goal is to achieve a frequency doubled clocking signal, would the "six easy pieces" asynchronous circuit be improved by inserting a GBUF at the output of the XNOR gate?Article: 95657
I forgot to tell. Of course at the other side of the link there will be a decryption unit to convert analog encrypted voice into real voice. Due to word wrap some text are not aligned in previous post . sorry.. yusufArticle: 95658
We are trying to make partial reconf with Virtex4 but ISE 8.1SP1 fails during the assembly phase. We want to test that "add-on module" but our copy of ISE is provided by EuroPractice for universities and we dont know how to contact with a FAE. Any suggestion? Javier On Sat, 21 Jan 2006 14:55:11 +0100, "Antti Lukats" <antti@openchip.org> wrote: >"GaLaKtIkUsT" <taileb.mehdi@gmail.com> schrieb im Newsbeitrag >news:1137847265.882963.14050@o13g2000cwo.googlegroups.com... >> Xilinx promised for ISE8.1i a "free add-on module for partial >> reconfiguration". But I still don't see it. >> Can anybody give me some precisions? >> >> Mehdi >> > >ASFAIK it is only available upon request from FAE, not freely downloadable > >antti >Article: 95659
Thanks everyone. This has been useful for me and others. Roger. "Brian Davis" <brimdavis@aol.com> wrote in message news:1138160016.066348.150980@f14g2000cwb.googlegroups.com... > Roger wrote: >> >> Thanks, this was really useful. >> > Glad that worked. > >> I'm using version 7.1 of ISE > > And, now I know what to change when I switch to 7.1 ! > > I haven't updated from 6.3 yet at home to create a test case, > but I've had problems with attributes not sticking to diff. buffers > before ( especially the _DIFF_OUT variants ) > >> >> I don't know why and probably never will but it allows me to >> progress with the design now. >> > I think Xilinx is getting away from the named suffixes for the > newer families, so perhaps they broke something in the tool flow. > > Brian >Article: 95660
Usually I will temper the use of "gates" by saying equivalency can be a factor of x2 or x 1/2 out. A better FPGA metric for Xilinx and Altera is number of LUTs and Flops but even here there are things to muddy the comparision. The technologies that are not SRAM based also don't compare easily on these metrics. John Adair Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 PCI-E Development Board. http://www.enterpoint.co.uk "int19h" <tirath@replacethispartwithmynickname.com> wrote in message news:43d6d3f8@dnews.tpgi.com.au... > Hi all, > > I need some advice on how to treat the "equivalent gate count" issue. I > have to make a presentation on something soon, where FPGAs are the initial > foundation of the project, and I anticipate having to provide some > correlation between "slices" and "gates" as an estimate to the capacity of > current-generation FPGAs. > > Ideally I would provide a slice and logic area estimate for the specific > design, but the design is not nearly complete enough to provide such > reliable estimates. For now, I have to arm-wave it. I don't need it to be > vendor-neutral though, I can be Xilinx specific. Any suggestions anyone? > > -int > >Article: 95661
Wait another 6 weeks and we will be showing something in Virtex-4 that can do this. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "mk" <kal*@dspia.*comdelete> wrote in message news:lacat1h0ukseb8pg6trd7fgedu2uv543ab@4ax.com... > Hi, > I am looking for a board with at least 16 balanced LVDS connections > able to run at 800 MHz, preferably A but X would be OK too. Any and > all suggestions are welcome. Of course the larger the FPGA the better, > and two or more FPGAs would be awesome :-) > > Thanks.Article: 95662
yusufilker@gmail.com wrote: > hi, > > I would like to implement a secure channel over an unsecure medium. > > mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A > conv =>voice > analog Host A/D digital > "other side" > > I do not want to encrypt data at the device's digital side > because it is unsecure, and I dont know how to interfere digital data > I don not have access to embedded software, source code etc. > (maybe just after host A/D converter and emulating Host A/D converter > to device,,,maybe) and > every encryption algorithm implemented here can be broken at the other > side I guess. > > What I want to do is ; > > mic(voice) => A/D conv + cpld or fpga + D/A conv =>A/D conv => unknown > comm link > analog ecrypt + scramble digital data voice like > encrypted signal Such scrambling may produce a lot of higher frequencies which after being filtered out by the equipment and the line result in data loss. ReneArticle: 95663
Ray Andraka wrote: > fpga_toys@yahoo.com wrote: > > So, my point is, and nobody seems to disagree, that it's unrealistic to > > assume that the devices can be 100% packed, use the marketing numbers > > for system design clock speeds, at a modest toggle rate, and not blow > > right thru the power the device can handle. Disagree? > You won't get the density and performance without handcrafting to meet > both the density and performance limits. The typical user is going to > run into place and route issues before he even gets close to the high > density, high clock rate corner. I don't care if it is an RC > application or not, you just don't get into that corner unless you do a > considerable amount of handcrafting on the design. Thanks for making my point. The Xilinx product chips + ISE is unable to route designs which have a high usage level, which is believe is because it both lacks routing resources and P&R needs improvement. You are probably one of better 1/4 of percent of engineers that might have the experience to beat P&R regularly ... but for the rest of us mortals the product isn't usabel as you get close to 100% packing. For RC uses I have a laundry list of things that are wrong with P&R, some of which are WHY you can not get high density designs routed with ISE. P&R fails to pack FF's with the LUT that has it's input term ... choosing instead to use another LUT as a pass thru that is several CLB's away. Given a netlist that is obviously a 6x15 mesh from the routing, it tends to place the parts in an arc around the center of the chip instead. ... and a number of other observations that says it's costing algorithms have a very different goal, and fail because of it for some designs. The problem is that P&R is not optional, they will not release the doc for an open source implementation which is turned to other applications, like RC. So until P&R can automatically route the same dense designs you pull off, I say the product chips+ISE isn't usable for dense designs. The reason they get away with it today is that for hardware design there is a VERY strong incentive to buy up ... purchase a larger device, just to make sure that in the future changes will fit. So many designs will always have the headroom, and presure on Xilinx to improve P&R for high density routing is relatively low, as few designs will cross above 95% use. With RC there is a completely different goal, and that is to use the entire chip, in fact, all of every chip in an FPGA processor array. High density designs are the norm with RC, and half device designs will be relatively rare.Article: 95664
fpga_toys@yahoo.com wrote: > The reason they get away with it today is that for hardware design > there is > a VERY strong incentive to buy up ... purchase a larger device, just to > make > sure that in the future changes will fit. So many designs will always > have the > headroom, and presure on Xilinx to improve P&R for high density routing > is > relatively low, as few designs will cross above 95% use. > > With RC there is a completely different goal, and that is to use the > entire chip, > in fact, all of every chip in an FPGA processor array. High density > designs are > the norm with RC, and half device designs will be relatively rare. Worse yet, RC will tend to use the largest chips available, or the largest chip with a reasonable cost performace. Buying up is not an option. In this arena, we are talking about fiting designs to a half million or more on chip resources (LUT's, FF's , MUX's, etc) -- and for multichip RC platforms target environments with easily 20M LUT's or more. This is so far past hand routing, it's beyond even suggesting. Automated tools are necessary to partition, route, place and optimize these large multichip projects ... P&R isn't even close to the right tool. Wanting a vendor to open up their tool chain to allow open source P&R at some point will not be just a request, or an option, it will become manditory for implementation dyamically loaded incrementally place and routed designs with libraries. The vendors that recognize that, and can produce large chips, will in the end own this high end commodity market. Being able to compile, load and go with 20M LUT netlists in a few seconds is what is necessary ... five days of P&R is not an option.Article: 95665
yusufilker@gmail.com wrote:
> hi,
>
> I would like to implement a secure channel over an unsecure medium.
>
> mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A
> conv =>voice
> analog Host A/D digital
> "other side"
>
> I do not want to encrypt data at the device's digital side
> because it is unsecure, and I dont know how to interfere digital data
> I don not have access to embedded software, source code etc.
> (maybe just after host A/D converter and emulating Host A/D converter
> to device,,,maybe) and
> every encryption algorithm implemented here can be broken at the other
> side I guess.
>
> What I want to do is ;
>
> mic(voice) => A/D conv + cpld or fpga + D/A conv =>A/D conv => unknown
> comm link
> analog ecrypt + scramble digital data voice like
> encrypted signal
>
> The Device will see voice freq signal and will transmit them through
> channel as if they are real voices.
> At this point adding some noise may help a lot.
> a little bit noise may fool attackers but human still can understand
> what is said.
>
>
> questions:
>
> what is possible weakness of this system?
> I am sure it can be still broken but
> how easy to break it?
> What kind of tools/approaches "they" are using ?
> Is cpld enough for general data encryption?
> (data is human voice so 8Kbps.)
> encrytion should be easy so the hacking also....
> they: whatever you say
This would be the minimum required to make a "professional-grade" voice
encryptor:
mic => ADC => compress => encrypt => frame =+
|
modem <=> comm link
|
spkr <= DAC <= decompress <= decrypt <= deframe
The compression (i.e. bit rate reduction) is needed because the voice
band modem won't get anything like the 64kbps required by A or mu law
8kHz audio.
Compression is already used for applications such as VOIP and mobile
phones for similar reasons.
For example, G.729 can reduce speech to 8 kbit/s.
The framing is needed because you'll probably use block based
encryption, and something needs to synchronise the blocks.
You will also need to inject and extract packets for key management,
etc.
Note that if the comm link has significant tx-rx crosstalk (e.g. if
it's a regular two wire phone line) you will require a DSP based
crosstalk canceller to get decent modem performance.
The compression, encryption and voice band modem functions could be
carried out in a regular DSP chip.
You will not be able to do this in a CPLD.
Trying to do this in an FPGA might be possible, but so is banging your
head against a wall.
Ask in news:comp.dsp about the modem and compression functions.
Ask in news:sci.crypt about the encrypt and decrypt functions. (Also
ask about the impact of bit errors in the modem.)
Regards,
Allan
Article: 95666yusufilker@gmail.com wrote: > hi, Howdy yusuf, see below... > I would like to implement a secure channel over an unsecure medium. > > mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A > conv =>voice > analog Host A/D digital > "other side" > > I do not want to encrypt data at the device's digital side > because it is unsecure, Why do you think it is unsecure? Hopefully a professor isn't telling you that, as I believe it's how most governmental and non-governmental encryption is done. > and I dont know how to interfere digital data > I don not have access to embedded software, source code etc. > (maybe just after host A/D converter and emulating Host A/D converter > to device,,,maybe) and > every encryption algorithm implemented here can be broken at the other > side I guess. What makes you say that "every encryption algorithm implemented here can be broken at the other side"? Why is it easy to break "here" and not somewhere else? > What I want to do is ; > > mic(voice) => A/D conv + cpld or fpga + D/A conv =>A/D conv => unknown > comm link > analog ecrypt + scramble digital data voice like > encrypted signal I'm not sure what a "voice like" encrypted signal would be, but I'm pretty sure that if someone could tell that it was voice like, it will not be secure. I'm also not sure what the purpose of all the A/D's and D/A's are, but that's a side issue that doesn't seem important to the rest of the discussion, so I'll just skip it. > The Device will see voice freq signal and will transmit them through > channel as if they are real voices. > At this point adding some noise may help a lot. > a little bit noise may fool attackers but human still can understand > what is said. I believe that adding randomness (noise) to the input signal/data that is about to be encrypted is bordering on security by obscurity, which in theory, adds little to no real protection to a determined attacker. In practice, you might be able to argue otherwise (maybe that every little bit of security helps?) - but know that modern cryptographers like to rely one thing and one thing only: the length of the key. They typically use algorithms that are known and respected industry wide. They use algorithms that have been peer reviewed many times over many years. > questions: > > what is possible weakness of this system? > I am sure it can be still broken but how easy to break it? > What kind of tools/approaches "they" are using ? With absolutely no disrespect intended, if you don't know what the strengths or weaknesses are of a system you are trying to design, or what kind of attackes someone might make on it, I'm afraid that a Usenet posting or two probably isn't going to help (even if it were from an experienced cryptographer, which I'm not). > Is cpld enough for general data encryption? > (data is human voice so 8Kbps.) > encrytion should be easy so the hacking also.... Compressing human voice down to 8 kbit/s requires a little bit of horsepower. It would not surprise me if it was beyond the capabilities of a CPLD, or if it is possible, would require an experienced coder that is very efficient in how they implement algorithms. Have fun, MarcArticle: 95667
sure, I know about all those scripting and makefile advantages, there have been enough wars on that. However, I _do_ like graphical user interfaces and once everything is set up, I can press one button to run the complete designflow over and over again... Some people like one, some the other, no worries, everybody is free. So thanks for your suggestion but I am not looking for a workaround but a real fix of the ISE GUI.Article: 95668
On 24 Jan 2006 22:01:42 -0800, "Eric" <dasani8888@hotmail.com> wrote: >Hi, > >I designed a simple adder using the add/import peripheral feature in >EDK. I removed the sum register in the write process, and add a >my_adder process to calculate the sum. Every time I run the test (a >sample software application), I get a 0 as the sum. I got both reg0 and >reg1 correct, but not the sum. Anyone has an idea what I've done wrong? >I can't figure if it's the code issue, or I am supposed to change some >setting in EDK. Thanks. > >part of my application code: > > MY_ADDER_mWriteReg(XPAR_MY_ADDER_0_BASEADDR, 0, 10); > MY_ADDER_mWriteReg(XPAR_MY_ADDER_0_BASEADDR, 0x4, 7); > sum = MY_ADDER_mReadReg(XPAR_MY_ADDER_0_BASEADDR, 0x8); > case slv_reg_read_select is > when "100" => slv_ip2bus_data <= slv_reg0; > when "010" => slv_ip2bus_data <= slv_reg1; > when "001" => slv_ip2bus_data <= slv_reg2; > when others => slv_ip2bus_data <= (others => '0'); > end case; The conversion from address to select is not given here... Do these addresses actually correspond to these read selects? You may have to simulate the design to find out. - BrianArticle: 95669
On a sunny day (25 Jan 2006 04:20:40 -0800) it happened allanherriman@hotmail.com wrote in <1138191640.397630.147570@o13g2000cwo.googlegroups.com>: >This would be the minimum required to make a "professional-grade" voice >encryptor: > > >mic => ADC => compress => encrypt => frame =+ Do not forget the anti-aliasing lowpass before the ADC.Article: 95670
>Marc Randolph" <mrand@my-deja.com> schrieb im Newsbeitrag >news:1138192752.155593.278520@z14g2000cwz.googlegroups.com... > yusufilker@gmail.com wrote: >> hi, > > Howdy yusuf, see below... > >> I would like to implement a secure channel over an unsecure medium. >> >> mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A Transmitting encrypted voice over band-limited analog link is VERY VERY complicated task. If you want secure and reliable connection over analog link that does not reduce the quality (eg provides almost the same bandwidth as clear channel) then calculate at least one man-year development time. Probably more. I have hacked an secured digital sound transmittion standard once a long time ago. It is amazing what has to be done to digitized voice in order to hide its nature of being voice data. Anything that is from our world eg sound, voice, captured image keeps its characteristics after large amount of distortion applied, things like bit swapping/interleaving, xor patterns do not change almost anything - methods exist to recover the original. -- Antti Lukats http://www.xilant.comArticle: 95671
hi It seems that, in Linux, we have to generate ICON,ILA core with command-line. I am starting to use chipscope pro 8.1. Problem is that it is too error-prone when I type the configuration (especially ILA) in command-line. Actually following command-line created "Directory stack not that deep" error message. -------------------------------------------------------------------------------------------------------------------------- > generate.sh ila -compname=my_ilaunit_0 -numtrigports=3 -trigportWidth0 =1 -trigportWidth1 =1 -trigportWidth2 =4 -mtype0 =5 -mtype1 =5 -mtype2 =4 -datasameastrig -datadepth=512 -datawidth=32 -enabledatatrig0 -enabledatatrig1 -enabledatatrig2 -enablestoragequal -outputdirectory="~/CSPro/" -srl16type=1 -devicefamily=Virtex2P -trigseqtype=1 -createcdc --------------------------------------------------------------------------------------------------------------------------- If someone has this experience, let us know how to solve this problem, ThankyouArticle: 95672
"Pasacco" <pasacco@gmail.com> schrieb im Newsbeitrag news:1138194183.393636.40370@z14g2000cwz.googlegroups.com... > hi > > It seems that, in Linux, we have to generate ICON,ILA core with > command-line. > I am starting to use chipscope pro 8.1. > > Problem is that it is too error-prone when I type the configuration > (especially ILA) in command-line. > Actually following command-line created "Directory stack not that deep" > error message. > > -------------------------------------------------------------------------------------------------------------------------- >> generate.sh ila -compname=my_ilaunit_0 -numtrigports=3 -trigportWidth0 >> =1 -trigportWidth1 =1 -trigportWidth2 =4 -mtype0 =5 -mtype1 =5 -mtype2 >> =4 -datasameastrig -datadepth=512 -datawidth=32 -enabledatatrig0 -enabledatatrig1 >> -enabledatatrig2 -enablestoragequal -outputdirectory="~/CSPro/" -srl16type=1 >> -devicefamily=Virtex2P -trigseqtype=1 -createcdc > --------------------------------------------------------------------------------------------------------------------------- > > If someone has this experience, let us know how to solve this problem, > Thankyou > your params when pasted into argument file and run with CS 8.1 on windows then it works with no problems. so if the same does not work on linix then the workaround is to use a windows PC for the ChipScope -- Antti Lukats http://www.xilant.comArticle: 95673
Phil Tomson wrote:
> But then someone brought up the fate of JHDLBits: apparently the prjoject was
> squashed by Xilinx. Does anyone have any details about what happened? If
> someone succeeded in developing an open source ecosystem of tools built around
> XDL, would that project also suffer the same fate? (It would be nice to know
> before investing much time and effort in developing tools around XDL)
The status from the team a year ago was:
"we are still trying to figure out a schedule with Xilinx
corporation on the release of the project. Xilinx funded the
research and
some parts of the project contained proprietary information, so
we have been
trying to come to an agreement. We are still hoping for a
release sometime
soon."
I've asked a several Xilinx staff about it both on and off the record.
On the record,
no reply. Off the record, "it will never happen". The fine print in
Xilinx tools licenses
is a claim preventing reverse engineering of the chip layouts and
databases, even
though this is clearly visible to the user from several tools ranging
from the fpga
editor to the bit stream generator. From what I have been told, any
compilation of
data base details into an open source equivalent P&R to bitstream tool
as was done
by the JHDLBits team will result in a C&D Order from Xilinx.
So, Xilinx let this team proceed, gained a lot of publicity from it as
marketing
collaterial, and then dashed the teams hopes of taking it open source.
I doubt
the team would have partnered with Xilinx had the outcome been clearly
stated
up front. They put a lot of energy into the project, then were told to
shutup and
walk away.
Much of what the FpgaC project needs to support compile, load, and go
for Xilinx
product is trapped in this project, with a clear warning from Xilinx to
stay clear.
The likely outcome is to focus on other vendors which are more willing
to allow
open source investment in RC technologies which support their products.
Article: 95674Doesn't the ml403 come with a Linux distribution? Why would you need to port anything? "ramesh" <ramesh@embeyond.com> wrote in message news:1138173378.715130.86900@g43g2000cwa.googlegroups.com... > Hi All, > Iam new to xilinx platfrom. > > I was trying to port open source linux on Ml403 board. i tried to > follow the instructions in the below link. > http://www.klingauf.de/v2p/index.phtml > i was getting errors when i was running bZimage. the .elf file was not > getting created. > > Is there an alternative way of acheiving my goal. > Kindly suggest. > Thanks in advance. > > Ramesh >
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