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
OKok, my Linux knowledge is on the edge but not gone: :-)
The important line is:
[pid 22097] open("/etc/hostid", O_RDONLY) = -1 ENOENT (No such file or
directory)
This told me that ISE is looking for the file /etc/hostid, which was
not existent at my computer.
However, the command "hostid" gives the right value. So I did " sudo
hostname > /etc/hostid" to create the file and voila: ISE starts in 5
seconds.
Problem solved !
Thanks for your help, I wouldn't have done it without all of your help
!
I hope, this helps everybody with the same problem.
Cheers, Joachim
Article: 95926
Hi,
I'm trying to learn the way to work with output buffers and other
features of the XC3S1000FG456 installed on my Analog Devices FPGA
extender board. This board has 3 connectors placed in such a way to be
able to connect it to a Blackfin DSP evaluation board, but it can work
stand-alone as a normal Spartan3 evaluation board and that's the way
I'm using it now.
I wanted to push out a signal and see how it behaves changing slew,
drive current and IO standard (the 3 attributes of the OBUF template).
I made a couple of examples in VHDL and I'd like you to tell me what
you think about the 2 different approaches.
First one:
OBUF_inst_slow : OBUF
generic map (
DRIVE => 16,
IOSTANDARD => "LVCMOS33",
SLEW => "SLOW")
port map (
O => slow_out, -- slow_out is the out port of my entity (same
for fast)
I => slow_sig_out -- slow_sig_out is the signal I want to send
out (same for fast)
);
OBUF_inst_fast : OBUF
generic map (
DRIVE => 16,
IOSTANDARD => "LVCMOS33",
SLEW => "FAST")
port map (
O => fast_out, -- Buffer output (connect directly to top-level
port)
I => fast_sig_out -- Buffer input
);
I places this snippet inside the architecture of my code and "check
syntax" tells me there are no errors in the VHDL.
Second one,
I commented the previous code and inserted the following lines in the
declaration part of the architecture section:
attribute slew : string;
attribute SLEW of fast_out : signal is "FAST";
attribute SLEW of slow_out : signal is "SLOW";
then I put these assignments just before the end of the behavioural
section:
fast_out <= fast_sig_out;
slow_out <= slow_sig_out;
and, finally, used these contraint in the UCF file associated with my
project:
inst "slow_out" iostandard = LVCMOS33;
inst "fast_out" iostandard = LVCMOS33;
inst "slow_out" drive = 16;
inst "fast_out" drive = 16;
Both the 2 approaches give me these kind of errors that do disappear
when I set the IOSTANDARD to DEFAULT (that should be LVTTL?):
ERROR:Place:311 - The IOB slow_out is locked to site PAD134 in bank 2.
This
ERROR:Place:311 - The IOB fast_out is locked to site PAD130 in bank 2.
This
ERROR:Place:207 - Due to SelectIO banking constraints, the IOBs in your
design
ERROR: PAR failed
On the Xilinx web site I saw that this issue comes out when you try to
force a, say, 3.3V standard on a bank supplied with 2.5V. It's only a
software bug that will be addressed in ISE 8.2. Whats surprises me is
that I have a jumper on my board to choose from 2.5V and 3.3V on the
Vcco banks and I set them all at 3.3V, so I don't understand why I get
this error working with a standard at 3.3V?
Could anyone help?
I'd appreciate any comment also on the 2 implementation.
Thanks in advance,
Marco
Article: 95927Eli Hughes <emh203@psu.edu> writes: > Has anyone got a chance to play with these devices? If so, any first > impressions? I was supremely disappointed when the Actel engineers told me that there was absolutely no support for partial reconfiguration (no matter how primitive or slow). - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380Article: 95928
"Adam Megacz" <megacz@cs.berkeley.edu> schrieb im Newsbeitrag news:x1oe1yf561.fsf@nowhere.com... > > Eli Hughes <emh203@psu.edu> writes: >> Has anyone got a chance to play with these devices? If so, any first >> impressions? > > I was supremely disappointed when the Actel engineers told me that > there was absolutely no support for partial reconfiguration (no matter > how primitive or slow). > > - a > Antti Lukats ----- Original Message ----- From: "Adam Megacz" <megacz@cs.berkeley.edu> Newsgroups: comp.arch.fpga Sent: Friday, January 27, 2006 9:25 AM Subject: Re: Actel Fusion > > Eli Hughes <emh203@psu.edu> writes: >> Has anyone got a chance to play with these devices? If so, any first >> impressions? > > I was supremely disappointed when the Actel engineers told me that > there was absolutely no support for partial reconfiguration (no matter > how primitive or slow). > > - a > well and I was disappointed when I was told that the Fusion kit what I ordered last year! and was supposedly from stock, is not going to be delivered for many months!! I have some PA3 silicon so I was going to use the FlashPro3 (bundled with Fusion kit) to program the PA3 parts I have. But as fusion kit delays I did build adapter from FlashPro for PA3 only to find out that the Actel software dosnt support programming of PA3 with FlashPro programmer even the hardware is compatible. then I looked at Actel DirectC for PA3 programming only to find out that last version of Actel DirectC doesnt support PA3, I was told that the support is planned to be released in March/April then I did recompile Actel STAPL player only to find out that Libero 7 generated STAPL file can not be used with Actel STAPL players latest version. This time I did not contact Actel anymore, I fixed the STAPL player to not fail, here is the project EXE and source, fixed and adopted to be compileable with MicroSofts free VC2005 Express compiler http://xilant.com/component/option,com_remository/Itemid,53/func,fileinfo/id,11/ I connected PA3 to Xilinx cable III, created a simple test design that writes 0 and 1 to IOpads, porgrammed the PA3 with the STAPL file generated programmaing and verify no errors. only bad thing is that the IO pads are all tristated as if the chip is not configured. strange -- Antti Lukats http://www.xilant.comArticle: 95929
Neil Steiner wrote: > As one of the four people who worked on JHDLBits, perhaps I can clear up > some of the misconceptions in this thread. > > 1. JHDLBits was indeed intended to be an open-source project, based upon > JBits as the bitstream interface. There was never any actual or > attempted reverse-engineering, because JBits already gave us the > necessary bitstream access. > > 2. The development team was pretty green, and though we came up with > some interesting stuff, the project was not robust (lack of > understanding of how and when to use exceptions, lack of understanding > of how to use public, private, and protected access, ...). > > 3. There was never any effort on the part of Xilinx, legal or otherwise, > to squash the project. We simply got to the end of the funding > agreement, had two people graduate, and another one eventually switch > departments. That left me, and I was only involved on the side because > of my familiarity with JBits and related tools, but I was busy working > on my own research with its own unrelated funding. > > 4. JHDLBits could still be a worthwhile open-source project, although > it's completely inactive at present, and if somebody with decent > software engineering skills feels like bringing it up to snuff, your > contribution would likely be welcomed with open arms. > > Neil Thanks Neil, I certainly stand corrected and the Information I had been given last Feburary, including the quote in this threads second post from another JHDLBits team member, has obviously been superceeded with your assertion that Xilinx is no longer blocking the release ... good news. There are certainly people to help you finish this project, if indeed Xilinx has provided written permission to take it open source. Clearly the Xilinx staffer that told me that would never happen wasn't that clueful about Xilinx's willingness to relax it's license for your great project. And that does indeed signal an a different spin on Xilinx and open source that is substantially more positive for the future. If you can transfer the sources to the the sourceforge repository, we will be very happy to help you pickup and complete the development. It might be useful to also include in that upload a copy of the Xilinx release letter. I do appologize for the confusion created by the out of date information that was given to me, and I passed on. JohnArticle: 95930
austin wrote: > Thank you for setting the record straight. I am sorry that John > Lawrence Bass (aka 'toys') has slandered the relationship, and the work > you did. > > I could not reveal the facts, as it would have violated your privacy and > our agreeements with our research colleagues (which we respect). > > Austin Austin, a lof of these threads have been about open, accurate, and timely release of information, and the confusion that is created when that process fails. It would not have violated the privacy to simply state that Xilinx had in fact provided the JHDLBits team a release on such and such a date, which you should have done, rather than letting the discussion degrade. Without that, older and inaccurate information is in fact, the most recient, and only information available.Article: 95931
"Marco" <marco@marylon.com> schrieb im Newsbeitrag news:1138350344.977213.189840@g43g2000cwa.googlegroups.com... > Hi, > I'm trying to learn the way to work with output buffers and other > features of the XC3S1000FG456 installed on my Analog Devices FPGA > extender board. This board has 3 connectors placed in such a way to be > able to connect it to a Blackfin DSP evaluation board, but it can work > stand-alone as a normal Spartan3 evaluation board and that's the way > I'm using it now. > I wanted to push out a signal and see how it behaves changing slew, > drive current and IO standard (the 3 attributes of the OBUF template). > I made a couple of examples in VHDL and I'd like you to tell me what > you think about the 2 different approaches. > > First one: > > OBUF_inst_slow : OBUF > generic map ( > DRIVE => 16, > IOSTANDARD => "LVCMOS33", > SLEW => "SLOW") > port map ( > O => slow_out, -- slow_out is the out port of my entity (same > for fast) > I => slow_sig_out -- slow_sig_out is the signal I want to send > out (same for fast) > ); > > OBUF_inst_fast : OBUF > generic map ( > DRIVE => 16, > IOSTANDARD => "LVCMOS33", > SLEW => "FAST") > port map ( > O => fast_out, -- Buffer output (connect directly to top-level > port) > I => fast_sig_out -- Buffer input > ); > > I places this snippet inside the architecture of my code and "check > syntax" tells me there are no errors in the VHDL. > > Second one, > I commented the previous code and inserted the following lines in the > declaration part of the architecture section: > > attribute slew : string; > attribute SLEW of fast_out : signal is "FAST"; > attribute SLEW of slow_out : signal is "SLOW"; > > then I put these assignments just before the end of the behavioural > section: > > fast_out <= fast_sig_out; > slow_out <= slow_sig_out; > > and, finally, used these contraint in the UCF file associated with my > project: > > inst "slow_out" iostandard = LVCMOS33; > inst "fast_out" iostandard = LVCMOS33; > > inst "slow_out" drive = 16; > inst "fast_out" drive = 16; > > Both the 2 approaches give me these kind of errors that do disappear > when I set the IOSTANDARD to DEFAULT (that should be LVTTL?): > > ERROR:Place:311 - The IOB slow_out is locked to site PAD134 in bank 2. > This > ERROR:Place:311 - The IOB fast_out is locked to site PAD130 in bank 2. > This > ERROR:Place:207 - Due to SelectIO banking constraints, the IOBs in your > design > ERROR: PAR failed > > On the Xilinx web site I saw that this issue comes out when you try to > force a, say, 3.3V standard on a bank supplied with 2.5V. It's only a > software bug that will be addressed in ISE 8.2. Whats surprises me is > that I have a jumper on my board to choose from 2.5V and 3.3V on the > Vcco banks and I set them all at 3.3V, so I don't understand why I get > this error working with a standard at 3.3V? > Could anyone help? > I'd appreciate any comment also on the 2 implementation. > Thanks in advance, > Marco > Hi Marco, Xilinx tools dont know and dont care about your jumper, only what you have specified in your design files. The FPGA doesnt care much either so you can select 2.5 or 3.3 in desgin and set jumper to 2.5 or 3.3 and in most cases everything still works. For maximum performance and standard compliance and voltage tolerance the bank io and standard setting must be correct. the default IOBANK VCC is different in different devices so if you use 3.3V standard in an bank that has any IO not set to 3.3 (eg left defualt) then the defaults (on S3) will yield to 2.5 and causes PAR to fail. in designs for modern Xilinx FPGAs S3/V4 it is recommended (my recommendation) to specify IOSTANDARD for ALL USED pins (located or not) only then you are sure that there will be no conflicts during PAR. AnttiArticle: 95932
Hallo, I would develop a system based on opb multichannel memory sdram controller. I would connect Microblaze to the controller using xcl and not opb bus. I would also connect an external microcontroller to sdram: I thought to create a custom opb master peripheral and connect it to opb bus. The opb bus will have a master (the external micro) and a slave (the sdram). Is it reliable? When I access memory from the external micro, may I use the address generated using EDK Platform Studio? In this way I should have the memory controller mapped in example at 0X22000000. May I use this address to gain access from microblaze and the external microcontroller? Many Thanks MarcoArticle: 95933
>Marco T." <marc@blabla.com> schrieb im Newsbeitrag >news:drcptn$ueq$1@nnrp.ngi.it... > Hallo, > I would develop a system based on opb multichannel memory sdram > controller. > > I would connect Microblaze to the controller using xcl and not opb bus. > > I would also connect an external microcontroller to sdram: I thought to > create a custom opb master peripheral and connect it to opb bus. > > The opb bus will have a master (the external micro) and a slave (the > sdram). > > Is it reliable? > > When I access memory from the external micro, may I use the address > generated using EDK Platform Studio? > > In this way I should have the memory controller mapped in example at > 0X22000000. > > May I use this address to gain access from microblaze and the external > microcontroller? > > Many Thanks > Marco > whatever you connect to OPB bus can not have access to memory on XCL as cachelink FSL bus is accessible only from MicroBlaze, not from busses connected to MB -- Antti Lukats http://www.xilant.comArticle: 95934
hi, for some devices xilinx ise offers an option to convert internal tristate buffers to equivalent logic. however, i cannot find any information how this works in detail. i understand that all tristate buffers driving one signal can be replaced by a multiplexer or equivalent logic. the problem is how the selector logic is derived from the original enable signals. if multiple enables are active concurrently, is there a sort of prioritization? why is the conversion restricted to specific devices? any hint, or even conference papers, manuals, etc. are very welcome. thank you in advance. dominikArticle: 95935
"Antti Lukats" <antti@openchip.org> wrote in message news:drcq39$imr$00$1@news.t-online.com... > >Marco T." <marc@blabla.com> schrieb im Newsbeitrag > >news:drcptn$ueq$1@nnrp.ngi.it... >> Hallo, >> I would develop a system based on opb multichannel memory sdram >> controller. >> >> I would connect Microblaze to the controller using xcl and not opb bus. >> >> I would also connect an external microcontroller to sdram: I thought to >> create a custom opb master peripheral and connect it to opb bus. >> >> The opb bus will have a master (the external micro) and a slave (the >> sdram). >> >> Is it reliable? >> >> When I access memory from the external micro, may I use the address >> generated using EDK Platform Studio? >> >> In this way I should have the memory controller mapped in example at >> 0X22000000. >> >> May I use this address to gain access from microblaze and the external >> microcontroller? >> >> Many Thanks >> Marco >> > whatever you connect to OPB bus can not have access to memory on XCL > as cachelink FSL bus is accessible only from MicroBlaze, not from busses > connected to MB > > -- > Antti Lukats > http://www.xilant.com > As usual, my english is terrible... I'm sorry! I try to be more clear. Microblaze will access sdram through XCL. Microblaze will NOT be connected to opb bus. An external micro will access sdram through OPB bus. It will be a master, the only master of the opb bus. The memory controller will be the only slave of opb bus. Is it reliable? Can Microblaze write a region of sdram and "simultaneously" external micro read another region? Sorry again! MarcoArticle: 95936
"Marco T." <marc@blabla.com> schrieb im Newsbeitrag news:drcqlq$um5$1@nnrp.ngi.it... > > "Antti Lukats" <antti@openchip.org> wrote in message > news:drcq39$imr$00$1@news.t-online.com... >> >Marco T." <marc@blabla.com> schrieb im Newsbeitrag >> >news:drcptn$ueq$1@nnrp.ngi.it... >>> Hallo, >>> I would develop a system based on opb multichannel memory sdram >>> controller. >>> >>> I would connect Microblaze to the controller using xcl and not opb bus. >>> >>> I would also connect an external microcontroller to sdram: I thought to >>> create a custom opb master peripheral and connect it to opb bus. >>> >>> The opb bus will have a master (the external micro) and a slave (the >>> sdram). >>> >>> Is it reliable? >>> >>> When I access memory from the external micro, may I use the address >>> generated using EDK Platform Studio? >>> >>> In this way I should have the memory controller mapped in example at >>> 0X22000000. >>> >>> May I use this address to gain access from microblaze and the external >>> microcontroller? >>> >>> Many Thanks >>> Marco >>> >> whatever you connect to OPB bus can not have access to memory on XCL >> as cachelink FSL bus is accessible only from MicroBlaze, not from busses >> connected to MB >> >> -- >> Antti Lukats >> http://www.xilant.com >> > > As usual, my english is terrible... I'm sorry! I try to be more clear. > > Microblaze will access sdram through XCL. Microblaze will NOT be connected > to opb bus. > > An external micro will access sdram through OPB bus. It will be a master, > the only master of the opb bus. The memory controller will be the only > slave of opb bus. > > Is it reliable? > > Can Microblaze write a region of sdram and "simultaneously" external micro > read another region? > > Sorry again! > > Marco > almost anything can be made reliable, but what you are suggesting is not REASONABLE. if SDRAM is on XCL then whatever external micro should access the SDRAM controller that does arbitration directly - using OPB here is not a good idea. AnttiArticle: 95937
Antti, I have to thank you very much (as always) for your suggestions. It now works, I specified the IOSTANDARD for all the used pins (some of them were LVCOMS25 as default looking inside the .pad_txt file) as an attribute within the declaration section of the architecture body. I've not been able to let it work setting those values inside the UCF as contraint (code 765, due to some parsing errors). Should I note differences in rise and fall time between fast and slow features? I found none. Thanks, MarcoArticle: 95938
"Antti Lukats" <antti@openchip.org> wrote in message news:drcqsu$2rq$02$1@news.t-online.com... > "Marco T." <marc@blabla.com> schrieb im Newsbeitrag > news:drcqlq$um5$1@nnrp.ngi.it... >> >> "Antti Lukats" <antti@openchip.org> wrote in message >> news:drcq39$imr$00$1@news.t-online.com... >>> >Marco T." <marc@blabla.com> schrieb im Newsbeitrag >>> >news:drcptn$ueq$1@nnrp.ngi.it... >>>> Hallo, >>>> I would develop a system based on opb multichannel memory sdram >>>> controller. >>>> >>>> I would connect Microblaze to the controller using xcl and not opb bus. >>>> >>>> I would also connect an external microcontroller to sdram: I thought to >>>> create a custom opb master peripheral and connect it to opb bus. >>>> >>>> The opb bus will have a master (the external micro) and a slave (the >>>> sdram). >>>> >>>> Is it reliable? >>>> >>>> When I access memory from the external micro, may I use the address >>>> generated using EDK Platform Studio? >>>> >>>> In this way I should have the memory controller mapped in example at >>>> 0X22000000. >>>> >>>> May I use this address to gain access from microblaze and the external >>>> microcontroller? >>>> >>>> Many Thanks >>>> Marco >>>> >>> whatever you connect to OPB bus can not have access to memory on XCL >>> as cachelink FSL bus is accessible only from MicroBlaze, not from busses >>> connected to MB >>> >>> -- >>> Antti Lukats >>> http://www.xilant.com >>> >> >> As usual, my english is terrible... I'm sorry! I try to be more clear. >> >> Microblaze will access sdram through XCL. Microblaze will NOT be >> connected to opb bus. >> >> An external micro will access sdram through OPB bus. It will be a master, >> the only master of the opb bus. The memory controller will be the only >> slave of opb bus. >> >> Is it reliable? >> >> Can Microblaze write a region of sdram and "simultaneously" external >> micro read another region? >> >> Sorry again! >> >> Marco >> > > almost anything can be made reliable, but what you are suggesting is not > REASONABLE. > > if SDRAM is on XCL then whatever external micro should access the SDRAM > controller > that does arbitration directly - using OPB here is not a good idea. > > Antti > > So, a better approach, could be that external micro accesses sdram through another XCL channel? I dont have found lots of information about developing a XCL master peripheral. What is your suggestion? Thanks Antti, your help is always precious! MarcoArticle: 95939
"Marco T." <marc@blabla.com> schrieb im Newsbeitrag news:drcrch$v1f$1@nnrp.ngi.it... > > "Antti Lukats" <antti@openchip.org> wrote in message > news:drcqsu$2rq$02$1@news.t-online.com... >> "Marco T." <marc@blabla.com> schrieb im Newsbeitrag >> news:drcqlq$um5$1@nnrp.ngi.it... >>> >>> "Antti Lukats" <antti@openchip.org> wrote in message >>> news:drcq39$imr$00$1@news.t-online.com... >>>> >Marco T." <marc@blabla.com> schrieb im Newsbeitrag >>>> >news:drcptn$ueq$1@nnrp.ngi.it... >>>>> Hallo, >>>>> I would develop a system based on opb multichannel memory sdram >>>>> controller. >>>>> >>>>> I would connect Microblaze to the controller using xcl and not opb >>>>> bus. >>>>> >>>>> I would also connect an external microcontroller to sdram: I thought >>>>> to create a custom opb master peripheral and connect it to opb bus. >>>>> >>>>> The opb bus will have a master (the external micro) and a slave (the >>>>> sdram). >>>>> >>>>> Is it reliable? >>>>> >>>>> When I access memory from the external micro, may I use the address >>>>> generated using EDK Platform Studio? >>>>> >>>>> In this way I should have the memory controller mapped in example at >>>>> 0X22000000. >>>>> >>>>> May I use this address to gain access from microblaze and the external >>>>> microcontroller? >>>>> >>>>> Many Thanks >>>>> Marco >>>>> >>>> whatever you connect to OPB bus can not have access to memory on XCL >>>> as cachelink FSL bus is accessible only from MicroBlaze, not from >>>> busses >>>> connected to MB >>>> >>>> -- >>>> Antti Lukats >>>> http://www.xilant.com >>>> >>> >>> As usual, my english is terrible... I'm sorry! I try to be more clear. >>> >>> Microblaze will access sdram through XCL. Microblaze will NOT be >>> connected to opb bus. >>> >>> An external micro will access sdram through OPB bus. It will be a >>> master, the only master of the opb bus. The memory controller will be >>> the only slave of opb bus. >>> >>> Is it reliable? >>> >>> Can Microblaze write a region of sdram and "simultaneously" external >>> micro read another region? >>> >>> Sorry again! >>> >>> Marco >>> >> >> almost anything can be made reliable, but what you are suggesting is not >> REASONABLE. >> >> if SDRAM is on XCL then whatever external micro should access the SDRAM >> controller >> that does arbitration directly - using OPB here is not a good idea. >> >> Antti >> >> > > > So, a better approach, could be that external micro accesses sdram through > another XCL channel? > > I dont have found lots of information about developing a XCL master > peripheral. > > What is your suggestion? > > Thanks Antti, your help is always precious! > > Marco > you need sdram controller that has XCL port to microblaze and defined by interface to your external micro. -- Antti Lukats http://www.xilant.comArticle: 95940
"Marco" <marco@marylon.com> schrieb im Newsbeitrag news:1138356403.072915.211360@g44g2000cwa.googlegroups.com... > Antti, I have to thank you very much (as always) for your suggestions. > It now works, I specified the IOSTANDARD for all the used pins (some of > them were LVCOMS25 as default looking inside the .pad_txt file) as an > attribute within the declaration section of the architecture body. I've > not been able to let it work setting those values inside the UCF as > contraint (code 765, due to some parsing errors). > Should I note differences in rise and fall time between fast and slow > features? > I found none. > Thanks, Marco > I have measuered the delay difference fast<>slow on S3 its pretty significant. but if you see the difference depends on your method of measuerment of course. -- Antti Lukats http://www.xilant.comArticle: 95941
Antti, I attached an oscilloscope on the 2 pins I use to read the same signal. The first pin is set to FAST, the other one to SLOW, but their rise and fall bahaviour is identical, I can overlap the 2 traces on the screen, so I think I'm wrong somewhere, even if on the .pad_txt file they appear to be correctly set. MarcoArticle: 95942
Austin Lesea <austin@xilinx.com> writes: > Afraid not. Spartan folks are just not into reconfiguring, unless it > is the whole bitstream. Seems they polled their customers, and even > though they have shipped 10 million S3's to date, they see no need... > So for S3, no. > Don't know about Spartan 3E. Well, the SNOWPLOW register is still there in S3E, right? I mean, it's not a walk in the park, but after Atmel and Virtex it's the next best thing (are you listening, Actel?) ;) - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380Article: 95943
I have been presented with a c program to implement on an fpga. I am investigating the possible processes/tools I could employ rather than a straight rewrite in VHDL. Current candidates are: Impulse C Handel-C Xilinx System Generator The algorithm is littered with sin cos sqrt & divides. So I expect that I require some of the xilinx IP cores that come with my ISE tool. (That's why XSG is getting a look in) Q. How do I implement this algorithm's cos functions (for example) in Impulse C so that it is represented in the resultant HW?Article: 95944
"Antti Lukats" <antti@openchip.org> wrote in message news:drcrn1$tge$03$1@news.t-online.com... > "Marco T." <marc@blabla.com> schrieb im Newsbeitrag > news:drcrch$v1f$1@nnrp.ngi.it... >> >> "Antti Lukats" <antti@openchip.org> wrote in message >> news:drcqsu$2rq$02$1@news.t-online.com... >>> "Marco T." <marc@blabla.com> schrieb im Newsbeitrag >>> news:drcqlq$um5$1@nnrp.ngi.it... >>>> >>>> "Antti Lukats" <antti@openchip.org> wrote in message >>>> news:drcq39$imr$00$1@news.t-online.com... >>>>> >Marco T." <marc@blabla.com> schrieb im Newsbeitrag >>>>> >news:drcptn$ueq$1@nnrp.ngi.it... >>>>>> Hallo, >>>>>> I would develop a system based on opb multichannel memory sdram >>>>>> controller. >>>>>> >>>>>> I would connect Microblaze to the controller using xcl and not opb >>>>>> bus. >>>>>> >>>>>> I would also connect an external microcontroller to sdram: I thought >>>>>> to create a custom opb master peripheral and connect it to opb bus. >>>>>> >>>>>> The opb bus will have a master (the external micro) and a slave (the >>>>>> sdram). >>>>>> >>>>>> Is it reliable? >>>>>> >>>>>> When I access memory from the external micro, may I use the address >>>>>> generated using EDK Platform Studio? >>>>>> >>>>>> In this way I should have the memory controller mapped in example at >>>>>> 0X22000000. >>>>>> >>>>>> May I use this address to gain access from microblaze and the >>>>>> external microcontroller? >>>>>> >>>>>> Many Thanks >>>>>> Marco >>>>>> >>>>> whatever you connect to OPB bus can not have access to memory on XCL >>>>> as cachelink FSL bus is accessible only from MicroBlaze, not from >>>>> busses >>>>> connected to MB >>>>> >>>>> -- >>>>> Antti Lukats >>>>> http://www.xilant.com >>>>> >>>> >>>> As usual, my english is terrible... I'm sorry! I try to be more clear. >>>> >>>> Microblaze will access sdram through XCL. Microblaze will NOT be >>>> connected to opb bus. >>>> >>>> An external micro will access sdram through OPB bus. It will be a >>>> master, the only master of the opb bus. The memory controller will be >>>> the only slave of opb bus. >>>> >>>> Is it reliable? >>>> >>>> Can Microblaze write a region of sdram and "simultaneously" external >>>> micro read another region? >>>> >>>> Sorry again! >>>> >>>> Marco >>>> >>> >>> almost anything can be made reliable, but what you are suggesting is not >>> REASONABLE. >>> >>> if SDRAM is on XCL then whatever external micro should access the SDRAM >>> controller >>> that does arbitration directly - using OPB here is not a good idea. >>> >>> Antti >>> >>> >> >> >> So, a better approach, could be that external micro accesses sdram >> through another XCL channel? >> >> I dont have found lots of information about developing a XCL master >> peripheral. >> >> What is your suggestion? >> >> Thanks Antti, your help is always precious! >> >> Marco >> > you need sdram controller that has XCL port to microblaze and defined by > interface to your external micro. > > > -- > Antti Lukats > http://www.xilant.com > > Xilinx Multi-Channel SDRAM Memory controller has 4 XCL ports. Microblaze uses 2 port. Now I should develop a XCL Master interface and connect it to one of the 2 free ports. But I don't have found any document about it. Only about connecting microblaze to memory. I could insert two microblaze into the project, but in what way may I execute different softwares? The second microblaze should only read and trasmit datas out of fpga.Article: 95945
Austin Lesea <austin@xilinx.com> writes: > It is unfair to the university(ies) or school(s) involved, and also > unfair to the company(ies) involved to continue with these allegations. Ugh, after this messy thread I think I'm going to be afraid to utter the phrase "open source" in the presence of Xilinx people at FPGA'06. Please understand that fpga_toy's attitude is very, very far from being typical of the people who actually make the big open source projects work. Richard Stallman was on campus a few months ago, and I spoke to him about the possibility of a "GNU Gateware Compiler" under the GCC umbrella. His response was quite positive, although after explaining the current bitstream situation it dimmed considerably. Even so, he remained eminently calm and never hostile or even indignant. I was quite impressed. My opinion is that it's just a matter of time before one of the vendors opens the bitstream format of one of their low-end devices (or Atmel comes out with a bigger device -- same effect). Personally, I'd much rather see it be Xilinx -- that would be convenient for me in a number of ways. But ultimately I'll be jumping on whichever boat leaves the pier first, likely taking a lot of impressionable young undergrads with me... ;) Cheers, - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380Article: 95946
In sci.electronics.design PraZ <prasanna.sethuraman@patni.com> wrote: > I don't completely comprehend what you mean by back propogation. But > yes, it is possible to get optimum probabilities for bits mapped to a > constellation symbol. You would find results on that if you search for > Bit Interleaved Coded Modulation, or BICM in short. If you get a decoded signal of any form coming through the viterbi decoder, a nice way of propagating back the actual symbol properties into the decisions.Article: 95947
simple JTAG Chain: Atmel-SAM7 ARM --> XC3S1500 --> XC9572XL attempt to configure FPGA with Impact, done not high configuration status register = 0000 attempt to program PLD seems to stall forever clicking abort and waiting makes impact again responsive with failure to program changing the BSDL file makes the chain order to get messed, attempt to re order the device by mouse drag and drop causes impact to self terminate. are there any issues with non Xilinx device in JTAG chain with impact 8.1? any help really welcome, I do not have time to open a webcase as I must have the board up and running til early next week. (the new bugs are entered in bugtrackter http://bugs.xilant.com ) -- Antti LukatsArticle: 95948
"John Williams" <jwilliams@itee.uq.edu.au> wrote in message news:newscache$i29qti$1kl$1@lbox.itee.uq.edu.au... > Symon wrote: > >> <allanherriman@hotmail.com> wrote in message >> news:1138195695.581945.80890@g44g2000cwa.googlegroups.com... >> >>>P.S. how did you know it was a sunny day here? >>> >> >> He's obviously been following the cricket now that Holland have qualified >> for the world cup. It looks sunny at the SCG in the picture of Jayasuriya >> after he hit a century! >> http://news.bbc.co.uk/sport1/hi/cricket/4634280.stm > > You know, there's just not enough talk about cricket on comp.arch.fpga. > > Perhaps a new group - comp.arch.fpga.cricket? > > John (who travels past the 'Gabba every day on the way to work...) > I'm not sure I'd get to work too often if I had that route to travel. Is the Gabba WiFi'd? As for comp.arch.fpga.cricket , I notice a lot of discussion on here about stuff like metastability in asynchronous fifos, running Linux on FPGA processors, EULAs/IP litigation. If we can't grasp simple concepts like that, I'm not sure we're ready to step up to the complexity of the LBW laws just yet. Cheers mate, Syms.Article: 95949
> The accesses on the xcl bus is only read cachemiss cacheline fills and > write through address/data. It's not a general bus for doing a fetch of a > whole matrix. Göran, I also have the same need: using multiport OPB sdram controller (better yet, the mch-ddr-opb, if it works) to connect OPB and two high bandwidth peripheral (ccd and vga controller). Can you give some pointer to relevant docs about XCL protocol ? Documentation is _very_ scarce on this subject. An example with MB for S3/S3E would really jumpstart my design. I would also pay some support fee for that!
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