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
On Jun 21, 4:21 pm, Jan Panteltje <pNaonStpealm...@yahoo.com> wrote: > On a sunny day (Thu, 21 Jun 2007 14:18:31 -0000) it happened Antti > <Antti.Luk...@googlemail.com> wrote in > <1182435511.771284.181...@g4g2000hsf.googlegroups.com>: > > > > > > >On Jun 21, 4:14 pm, pantel...@yahoo.com wrote: > >> On 21 jun, 13:49, Antti <Antti.Luk...@googlemail.com> wrote: > > >> > On Jun 21, 1:44 pm, Jan Panteltje <pNaonStpealm...@yahoo.com> wrote: > >> > eh, if you read my replies, then I did not outrule this to be > >> > implementatble in "3 USD FPGA", > >> > there are not so many FPGA with <= 3 USD price tag. And yes fitting > >> > into to cheapest FPGA > >> > would require near-magical engineering, but could be doable. > > >> > Antti > > >> Yes, if you have an 8 bit port, and 8 cards, use the cards in SPI mode > >> (DO,DI,CS,Clk) one card per bit, then if 200kB / sec you get > >> 16 MB/sec...... not even bad. > >> Optimizing would bring that to (I think I have seen 800kB/s reported > >> in SPI) > >> 64 MB /sec read.... > >> So that would use _very_simple logic, why keep to any spec... your own > >> driver. > > >the OP was talking about device that > > >1) is FULLY ATA compliant > >2) is FULLY SD Card compliant > >3) uses 2 SD cards both in 4 bit mode to maximize speed > > >this has nothing todo with "own spec" and SPI mode > > >Antti > > I do not care what OP was talking about, I _do_ care how I could do it. > SDcard spec is expensive you know? > WTF do I need it for if it can be done in an other way. > We were looking for _cheap_ solutions right? Else you just buy a flash disk.- Hide quoted text - > > - Show quoted text - WTF ?! _cheap_ things do not have to be shit, or am I mistaken here? the 8*SPI in parallel is hardly more expensive in hardware terms then proper design. besides the SPI parallel trick need read sync as even same card will not respond with same clock cycle delay to read commands, so the clock lines need separate steering. It way more reasonable to make device that runs 2 SD card in parallel (in 4 bit mode) AnttiArticle: 120976
On Jun 21, 4:03 pm, "Amontec, Larry" <laurent.ga...@ANTI- SPAMamontec.com> wrote: > Antti wrote: > > On 19 Jun., 17:00, cs_post...@hotmail.com wrote: > > >>On Jun 19, 9:56 am, Antti <Antti.Luk...@googlemail.com> wrote: > > >>>>Yes, that's odd, but doesn't bar us from begining a comparison. > > >>>>How fast have you documented the Xilinx cable going? > > >>>yes that ODD > > >>>and yes it does prevent comparison, actually ;) > >>>the USB performance can be influenced by many things, > >>>it could be that amontec used FS only hub or root port as example, > > >>So how fast have _you_ gotten the xilinx cable to go? > > >>You seem to be having more fun laughing at Larry's calendar challenges > >>than actually seeking to compare performance. > > >>The Amontec claimed performance, while yet unverified, doesn't seem > >>unreasble to me, so I'm really curious if you have evidence that the > >>xilinx cable is working faster than that for you? > > > actually as you have asked the same thing question SO MANY times, here > > is the answer > > YES, Xilinx Platform cable WORKS FASTER. > > > example: 11MBit bitstream, REDUCED TCK Clock to 12MHz, time : 2.547 > > seconds > > > On the test board the JTAG chain clock isnt optimal so I can not test > > at 24MHz TCK, > > I assume the speed performance would be noticeable. > > > this doesnt mean that Xilinx software and drivers are good, they are > > not, many JTAG operations > > could be carried out faster then do, but eh, this is the same thing as > > with Actel, they changed to > > use windriver USB drivers, and as result their programming times > > increased 2 times. > > > but hardware wise the Xilinx Platform USB cable is defenetly capable > > to get much better performance > > then any implementation of FT2232 in plastic box (== Amontec jtagkey, > > etc..) ever can. FT2232 has > > limitation on max JTAG clock of 6MHz. > > > Antti > > Dear Antti, > > Sorry for the delay, but last Friday was the big CRASH. We received > lightning on Amontec's House... the lightning comes in over LAN ! We > lost 5 computers ! Our servers protected by UPS are safe, HOUFFF ! > > Strange meteo in Switzerland at this moment. > > ...- Hide quoted text - > > - Show quoted text - brrr :( too bad the lightning strike, and lost computers. and too bad tha the "source code" published is 100% useless, as all the actual JTAG handling is hidden in an DLL and there is no source code available for it. AnttiArticle: 120977
cs_posting@hotmail.com wrote: > On Jun 21, 9:03 am, "Amontec, Larry" <laurent.ga...@ANTI- > SPAMamontec.com> wrote: > > >>Sorry for the delay, but last Friday was the big CRASH. We received >>lightning on Amontec's House... the lightning comes in over LAN ! We >>lost 5 computers ! Our servers protected by UPS are safe, HOUFFF ! > > > Sorry to hear that. > > You do appear to have recently posted some code for an SVF player. > Always good to see manufacturer's providing real user flexibility in > using their products! > > Is this code the how-to for the JTAG speed claim? > > Was the comparison to a Xilinx cable also run in SVF file mode, or did > you have impact reading a native xilinx bitstream file? > Yes, this is the how-to code. But the power of this solution is to be a generic JTAG solution because the SVF is a portable, FPGA / CPLD vendor independent! (Antti will not be OK with me, but vendor have to respect SVF specification. Our parser does :-) ) An other () : ( we will prove that we can program a ARM7 or ARM9 via SVF too ! Running a native xilinx bitstream could be a bit faster than we do not have to read and parse SVF file, but just take the .bit and upload it byte-after-byte. With the support of AmtXHAL, a native bitstream solution could be build in 1 or 2 hours for us (some hours for beginners) ... we could write an example if you need. Native bitstream stays custom solutions depending on number of chained Targets. But you are right, in test / program production stage, secondes could be important. LaurentArticle: 120978
Sorry for this newbie-like question, but I can't remember how I did it before for the life of me. Normally I pre-select certain signals before I run the sim, and look at those in waves. The problem is, if you want to look at signals that weren't pre-selected, you have to select them and re-run the sim, which is time-consuming. I know there is a way so that you can have all signals (or all submodule signals) simulated and stored in a database so you can drag necessary signals into the waves as needed. This is without having all signals show up in the waves. I thought this was a Modelsim command. Or, is it a language specific command in the design/tb? Help? Thanks,Article: 120979
On Jun 21, 4:08 pm, fastgreen2...@yahoo.com wrote: > Sorry for this newbie-like question, but I can't remember how I did it > before for the life of me. > > Normally I pre-select certain signals before I run the sim, and look > at those in waves. The problem is, if you want to look at signals > that weren't pre-selected, you have to select them and re-run the sim, > which is time-consuming. > > I know there is a way so that you can have all signals (or all > submodule signals) simulated and stored in a database so you can drag > necessary signals into the waves as needed. This is without having > all signals show up in the waves. > > I thought this was a Modelsim command. Or, is it a language specific > command in the design/tb? Help? > > Thanks, log -r * RobArticle: 120980
On a sunny day (Thu, 21 Jun 2007 14:45:41 -0000) it happened Antti
<Antti.Lukats@googlemail.com> wrote in
<1182437141.999975.188860@n2g2000hse.googlegroups.com>:
>> I do not care what OP was talking about, I _do_ care how I could do it.
>> SDcard spec is expensive you know?
>> WTF do I need it for if it can be done in an other way.
>> We were looking for _cheap_ solutions right? Else you just buy a flash disk.- Hide quoted text -
>>
>> - Show quoted text -
>
>WTF ?!
>
>_cheap_ things do not have to be shit, or am I mistaken here?
>
>the 8*SPI in parallel is hardly more expensive in hardware terms then
>proper design.
>
>besides the SPI parallel trick need read sync as even same card will
>not respond with same clock cycle delay to read commands, so the clock
>lines need separate steering. It way more reasonable to make device
>that runs 2 SD card in parallel (in 4 bit mode)
>
>Antti
From:
http://en.wikipedia.org/wiki/Secure_Digital_card
------------------------------------------------------------
Technical explanation
SD supports at least three transfer modes:
* One-bit SD mode (separate command and data channels and a proprietary transfer format)
* Four-bit SD mode (uses extra pins plus some reassigned pins)
* SPI mode (basically, a simpler subset of the SD protocol for use with microcontrollers)
All memory cards must support all three modes, except for microSD where SPI
is optional. The cards must also support clock frequencies of up to 25 MHz
for regular cards, and 50 MHz for high-speed cards.
Royalties for SD/SDIO licenses are imposed for manufacture and sale of
memory cards and host adapters ($1000 per year plus membership at
$1500/year) but SDIO cards can be made without royalties and MMC host
adapters do not require a royalty.
-------------------------------------------------------------
So, I dunno. SD 2500$ /year for an adapter, how many cards will you sell? 10?
Do I see this right?
8 SD or MMC cards of 1GB is now about 64 Euro I think.
10 Euro for the rest of the parts.
250 for the license??????? Not counting other IP you will need.
You tell me.
I think if cards from the same batch are used the timing issue is not that different.
But you are right, you'd need to monitor for CRC or whatever, and wait for all 8 cards
to complete.
But the same issue applies for any other system, even or even more so if you want
to 'stagger' the cards as in this example, maybe that is why so much logic?
Maybe the guy who designed that board ran into this.
Article: 120981Antti wrote: > On Jun 21, 4:03 pm, "Amontec, Larry" <laurent.ga...@ANTI- > SPAMamontec.com> wrote: > >>Antti wrote: >> >>>On 19 Jun., 17:00, cs_post...@hotmail.com wrote: >> >>>>On Jun 19, 9:56 am, Antti <Antti.Luk...@googlemail.com> wrote: >> >>>>>>Yes, that's odd, but doesn't bar us from begining a comparison. >> >>>>>>How fast have you documented the Xilinx cable going? >> >>>>>yes that ODD >> >>>>>and yes it does prevent comparison, actually ;) >>>>>the USB performance can be influenced by many things, >>>>>it could be that amontec used FS only hub or root port as example, >> >>>>So how fast have _you_ gotten the xilinx cable to go? >> >>>>You seem to be having more fun laughing at Larry's calendar challenges >>>>than actually seeking to compare performance. >> >>>>The Amontec claimed performance, while yet unverified, doesn't seem >>>>unreasble to me, so I'm really curious if you have evidence that the >>>>xilinx cable is working faster than that for you? >> >>>actually as you have asked the same thing question SO MANY times, here >>>is the answer >>>YES, Xilinx Platform cable WORKS FASTER. >> >>>example: 11MBit bitstream, REDUCED TCK Clock to 12MHz, time : 2.547 >>>seconds >> >>>On the test board the JTAG chain clock isnt optimal so I can not test >>>at 24MHz TCK, >>>I assume the speed performance would be noticeable. >> >>>this doesnt mean that Xilinx software and drivers are good, they are >>>not, many JTAG operations >>>could be carried out faster then do, but eh, this is the same thing as >>>with Actel, they changed to >>>use windriver USB drivers, and as result their programming times >>>increased 2 times. >> >>>but hardware wise the Xilinx Platform USB cable is defenetly capable >>>to get much better performance >>>then any implementation of FT2232 in plastic box (== Amontec jtagkey, >>>etc..) ever can. FT2232 has >>>limitation on max JTAG clock of 6MHz. >> >>>Antti >> >>Dear Antti, >> >>Sorry for the delay, but last Friday was the big CRASH. We received >>lightning on Amontec's House... the lightning comes in over LAN ! We >>lost 5 computers ! Our servers protected by UPS are safe, HOUFFF ! >> >>Strange meteo in Switzerland at this moment. >> >>...- Hide quoted text - >> >>- Show quoted text - > > > brrr :( too bad the lightning strike, and lost computers. > > and too bad tha the "source code" published is 100% useless, as all > the actual JTAG handling is hidden in an DLL and there is no source > code available for it. > > Antti > > > > Dear Antti, Did you try it ? or do you only search open sources ? Is a work too bad and 100% useless because it does not provide ALL in Open-Source? Do you make $$$ multi-donations for an Open-Source project? We have the replies. Amontec team works daily for providing real user flexibility and solutions in using Amontec products ... Our SVF player based on AmtXHAL is a very powerfull solution. And it is FREE. Our JTAG Hardware Abstration Layer is a big work too. We will put all code as Open-Source when our JTAGkey21 and JTAGkey24 will be ready for sales. These two new products will be based on USB2.0 high-speed processors and we already know that we will have the faster worldwide JTAG solutions). If you are designing from AmtXHAL, the use of JTAGkey21 and JTAGkey24 will be transparent for you ! You have to see yourself, but you'll see soon ! LarryArticle: 120982
On Jun 21, 9:54 am, Antti <Antti.Luk...@googlemail.com> wrote: > and too bad tha the "source code" published is 100% useless, as all > the actual JTAG handling is hidden in an DLL and there is no source > code available for it. Strongly disagree. First you can use it as intended. Then you can use the functions in the provided header file to accomplish various other jtag tasks. And if you really want to understand it, well, you have a header file for Larry's DLL, and Larry's DLL calls the FTD2xx.dll. So you make up a fake version of the later, and see what a given trial call to Larry's DLL produces in terms of FTD2xx operations... Yeah, reverse engineering, but simpler than reverse engineering the xilinx stuff, and people have done that!Article: 120983
Hi Laurent
I am ready to use it if you could provide me with a link
from where i could download it i guess this is my last chance of
running it..I am getting a little frustrated as i have not been able
to run xilinx completely on linux..A little help can really help me
out..Waiting for your reply..
Regards
Ankit Anand
Article: 120984On 21 Jun., 17:21, Jan Panteltje <pNaonStpealm...@yahoo.com> wrote: > On a sunny day (Thu, 21 Jun 2007 14:45:41 -0000) it happened Antti > <Antti.Luk...@googlemail.com> wrote in > <1182437141.999975.188...@n2g2000hse.googlegroups.com>: > > > > > > >> I do not care what OP was talking about, I _do_ care how I could do it. > >> SDcard spec is expensive you know? > >> WTF do I need it for if it can be done in an other way. > >> We were looking for _cheap_ solutions right? Else you just buy a flash disk.- Hide quoted text - > > >> - Show quoted text - > > >WTF ?! > > >_cheap_ things do not have to be shit, or am I mistaken here? > > >the 8*SPI in parallel is hardly more expensive in hardware terms then > >proper design. > > >besides the SPI parallel trick need read sync as even same card will > >not respond with same clock cycle delay to read commands, so the clock > >lines need separate steering. It way more reasonable to make device > >that runs 2 SD card in parallel (in 4 bit mode) > > >Antti > > From: > http://en.wikipedia.org/wiki/Secure_Digital_card > ------------------------------------------------------------ > Technical explanation > > SD supports at least three transfer modes: > > * One-bit SD mode (separate command and data channels and a proprietary transfer format) > * Four-bit SD mode (uses extra pins plus some reassigned pins) > * SPI mode (basically, a simpler subset of the SD protocol for use with microcontrollers) > > All memory cards must support all three modes, except for microSD where SPI > is optional. The cards must also support clock frequencies of up to 25 MHz > for regular cards, and 50 MHz for high-speed cards. > > Royalties for SD/SDIO licenses are imposed for manufacture and sale of > memory cards and host adapters ($1000 per year plus membership at > $1500/year) but SDIO cards can be made without royalties and MMC host > adapters do not require a royalty. > ------------------------------------------------------------- > > So, I dunno. SD 2500$ /year for an adapter, how many cards will you sell? 10? > Do I see this right? > 8 SD or MMC cards of 1GB is now about 64 Euro I think. > 10 Euro for the rest of the parts. > 250 for the license??????? Not counting other IP you will need. > > You tell me. > > I think if cards from the same batch are used the timing issue is not that different. > But you are right, you'd need to monitor for CRC or whatever, and wait for all 8 cards > to complete. > But the same issue applies for any other system, even or even more so if you want > to 'stagger' the cards as in this example, maybe that is why so much logic? > Maybe the guy who designed that board ran into this.- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - the read delay is can be way different as it depends on the amount and location of bad blonks in the NAND, this is all transparent to the user, but the black management is done by the SD cards, what can cause essential difference in response times. AnttiArticle: 120985
On 21 Jun., 17:47, cs_post...@hotmail.com wrote: > On Jun 21, 9:54 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > and too bad tha the "source code" published is 100% useless, as all > > the actual JTAG handling is hidden in an DLL and there is no source > > code available for it. > > Strongly disagree. > > First you can use it as intended. > > Then you can use the functions in the provided header file to > accomplish various other jtag tasks. > > And if you really want to understand it, well, you have a header file > for Larry's DLL, and Larry's DLL calls the FTD2xx.dll. So you make up > a fake version of the later, and see what a given trial call to > Larry's DLL produces in terms of FTD2xx operations... Yeah, reverse > engineering, but simpler than reverse engineering the xilinx stuff, > and people have done that! eh there is absolutly no sense to RE Larry DLL's ;) its nothing magical to found there. the "functions provided" did look like primitive replacement for something calles "command line parameter passing" - but well I only looked 2 minutes, maybe there is something more to see. But what I did see did look like useless. I would prefer just run from batch file, then using this customization API AnttiArticle: 120986
On a sunny day (Thu, 21 Jun 2007 15:59:58 -0000) it happened Antti <Antti.Lukats@googlemail.com> wrote in <1182441598.119110.72870@n60g2000hse.googlegroups.com>: >> I think if cards from the same batch are used the timing issue is not that different. >> But you are right, you'd need to monitor for CRC or whatever, and wait for all 8 cards >> to complete. >> But the same issue applies for any other system, even or even more so if you want >> to 'stagger' the cards as in this example, maybe that is why so much logic? >> Maybe the guy who designed that board ran into this.- Zitierten Text ausblenden - >> >> - Zitierten Text anzeigen - > >the read delay is can be way different as it depends on the amount and >location of bad blonks in the NAND, this is all transparent to the >user, but the black management is done by the SD cards, what can cause >essential difference in response times. > >Antti OK, I have been thinking a bit, and it seems to me we are not going to see many of these cards on the market. It is simpler for a manufacturer to just solder some FLASH chips on a board, it is more reliable (no connectors), no expensive protocol (both financial and as overhead), FLASH is still falling in price (some 'up' predicted for next year perhaps). Maybe the FLASH chips are even cheaper then the SDcard connectors ;-) You'd have to do bad sector handling on board, but so what. Let's forget about this product :-)Article: 120987
Antti wrote: > On 21 Jun., 17:47, cs_post...@hotmail.com wrote: > >>On Jun 21, 9:54 am, Antti <Antti.Luk...@googlemail.com> wrote: >> >> >>>and too bad tha the "source code" published is 100% useless, as all >>>the actual JTAG handling is hidden in an DLL and there is no source >>>code available for it. >> >>Strongly disagree. >> >>First you can use it as intended. >> >>Then you can use the functions in the provided header file to >>accomplish various other jtag tasks. >> >>And if you really want to understand it, well, you have a header file >>for Larry's DLL, and Larry's DLL calls the FTD2xx.dll. So you make up >>a fake version of the later, and see what a given trial call to >>Larry's DLL produces in terms of FTD2xx operations... Yeah, reverse >>engineering, but simpler than reverse engineering the xilinx stuff, >>and people have done that! > > > eh there is absolutly no sense to RE Larry DLL's ;) > its nothing magical to found there. > > the "functions provided" did look like primitive replacement for > something calles > "command line parameter passing" - but well I only looked 2 minutes, > maybe there > is something more to see. But what I did see did look like useless. > I would prefer just run from batch file, then using this customization > API > > Antti > > > > > > > > Electronic is not Magic but Logic. Only Physic is Magic! True Random Number Generator is Magic and Physic but use some Electronics! It is very simple to talk and think about True Random Number but you need more than 2 minutes for developing a True Random Number Generator! Bla - bla ... as your bla - bla Antti. Antti, you CANNOT take 2 minutes and then resume by a "too bad" and by a "100% useless". LaurentArticle: 120988
On 21 Jun., 18:16, Jan Panteltje <pNaonStpealm...@yahoo.com> wrote: > On a sunny day (Thu, 21 Jun 2007 15:59:58 -0000) it happened Antti > <Antti.Luk...@googlemail.com> wrote in > <1182441598.119110.72...@n60g2000hse.googlegroups.com>: > > >> I think if cards from the same batch are used the timing issue is not that different. > >> But you are right, you'd need to monitor for CRC or whatever, and wait for all 8 cards > >> to complete. > >> But the same issue applies for any other system, even or even more so if you want > >> to 'stagger' the cards as in this example, maybe that is why so much logic? > >> Maybe the guy who designed that board ran into this.- Zitierten Text ausblenden - > > >> - Zitierten Text anzeigen - > > >the read delay is can be way different as it depends on the amount and > >location of bad blonks in the NAND, this is all transparent to the > >user, but the black management is done by the SD cards, what can cause > >essential difference in response times. > > >Antti > > OK, I have been thinking a bit, and it seems to me we are not going to see many of > these cards on the market. > It is simpler for a manufacturer to just solder some FLASH chips on a board, it > is more reliable (no connectors), no expensive protocol (both financial and as overhead), > FLASH is still falling in price (some 'up' predicted for next year perhaps). > Maybe the FLASH chips are even cheaper then the SDcard connectors ;-) > You'd have to do bad sector handling on board, but so what. > Let's forget about this product :-) you can forget ;) eh well I am doing several projects that are using SD Cards, so I keep my mind open as of nand Flash there are NAND flash with built in ATA and there are NAND flash with built in SD card interface and there are NAND flash with built in USB interface and NAND flash with "differential clock" for high speed ... so lots of thinking, what makes sense and where.. AnttiArticle: 120989
On 21 Jun., 18:41, "Amontec, Larry" <laurent.ga...@ANTI- SPAMamontec.com> wrote: > Antti wrote: > > On 21 Jun., 17:47, cs_post...@hotmail.com wrote: > > >>On Jun 21, 9:54 am, Antti <Antti.Luk...@googlemail.com> wrote: > > >>>and too bad tha the "source code" published is 100% useless, as all > >>>the actual JTAG handling is hidden in an DLL and there is no source > >>>code available for it. > > >>Strongly disagree. > > >>First you can use it as intended. > > >>Then you can use the functions in the provided header file to > >>accomplish various other jtag tasks. > > >>And if you really want to understand it, well, you have a header file > >>for Larry's DLL, and Larry's DLL calls the FTD2xx.dll. So you make up > >>a fake version of the later, and see what a given trial call to > >>Larry's DLL produces in terms of FTD2xx operations... Yeah, reverse > >>engineering, but simpler than reverse engineering the xilinx stuff, > >>and people have done that! > > > eh there is absolutly no sense to RE Larry DLL's ;) > > its nothing magical to found there. > > > the "functions provided" did look like primitive replacement for > > something calles > > "command line parameter passing" - but well I only looked 2 minutes, > > maybe there > > is something more to see. But what I did see did look like useless. > > I would prefer just run from batch file, then using this customization > > API > > > Antti > > Electronic is not Magic but Logic. Only Physic is Magic! > True Random Number Generator is Magic and Physic but use some Electronics! > > It is very simple to talk and think about True Random Number but you > need more than 2 minutes for developing a True Random Number Generator! > > Bla - bla ... as your bla - bla Antti. > > Antti, you CANNOT take 2 minutes and then resume by a "too bad" and by a > "100% useless". > > Laurent- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - bla-bla, BTW how did you test that your DLL can handle "infinite" length chain? if I make SVF file that does masked compare and has single chain length of 33GBit, this would then be executed ok? 33G is defenetly less than infinite I think? and if I look at 2 pages of source code, then 2 minutes can tell a lot already AnttiArticle: 120990
On 21 Jun., 17:40, "Amontec, Larry" <laurent.ga...@ANTI- SPAMamontec.com> wrote: > Antti wrote: > > On Jun 21, 4:03 pm, "Amontec, Larry" <laurent.ga...@ANTI- > > SPAMamontec.com> wrote: > > >>Antti wrote: > > >>>On 19 Jun., 17:00, cs_post...@hotmail.com wrote: > > >>>>On Jun 19, 9:56 am, Antti <Antti.Luk...@googlemail.com> wrote: > > >>>>>>Yes, that's odd, but doesn't bar us from begining a comparison. > > >>>>>>How fast have you documented the Xilinx cable going? > > >>>>>yes that ODD > > >>>>>and yes it does prevent comparison, actually ;) > >>>>>the USB performance can be influenced by many things, > >>>>>it could be that amontec used FS only hub or root port as example, > > >>>>So how fast have _you_ gotten the xilinx cable to go? > > >>>>You seem to be having more fun laughing at Larry's calendar challenges > >>>>than actually seeking to compare performance. > > >>>>The Amontec claimed performance, while yet unverified, doesn't seem > >>>>unreasble to me, so I'm really curious if you have evidence that the > >>>>xilinx cable is working faster than that for you? > > >>>actually as you have asked the same thing question SO MANY times, here > >>>is the answer > >>>YES, Xilinx Platform cable WORKS FASTER. > > >>>example: 11MBit bitstream, REDUCED TCK Clock to 12MHz, time : 2.547 > >>>seconds > > >>>On the test board the JTAG chain clock isnt optimal so I can not test > >>>at 24MHz TCK, > >>>I assume the speed performance would be noticeable. > > >>>this doesnt mean that Xilinx software and drivers are good, they are > >>>not, many JTAG operations > >>>could be carried out faster then do, but eh, this is the same thing as > >>>with Actel, they changed to > >>>use windriver USB drivers, and as result their programming times > >>>increased 2 times. > > >>>but hardware wise the Xilinx Platform USB cable is defenetly capable > >>>to get much better performance > >>>then any implementation of FT2232 in plastic box (== Amontec jtagkey, > >>>etc..) ever can. FT2232 has > >>>limitation on max JTAG clock of 6MHz. > > >>>Antti > > >>Dear Antti, > > >>Sorry for the delay, but last Friday was the big CRASH. We received > >>lightning on Amontec's House... the lightning comes in over LAN ! We > >>lost 5 computers ! Our servers protected by UPS are safe, HOUFFF ! > > >>Strange meteo in Switzerland at this moment. > > >>...- Hide quoted text - > > >>- Show quoted text - > > > brrr :( too bad the lightning strike, and lost computers. > > > and too bad tha the "source code" published is 100% useless, as all > > the actual JTAG handling is hidden in an DLL and there is no source > > code available for it. > > > Antti > > Dear Antti, > > Did you try it ? or do you only search open sources ? > Is a work too bad and 100% useless because it does not provide ALL in > Open-Source? > Do you make $$$ multi-donations for an Open-Source project? We have the > replies. > > Amontec team works daily for providing real user flexibility and > solutions in using Amontec products ... > really? i have a chameleon, this is PURCHASED not your free gift (that one did burn in), but I can not use chameleon as solutions provided by amontec do not not support chameleon when LPT base address is not default (like PCI LPT) there is solution to reconfigure Amontex chameleon connected to PCI LPT, but this solution is PINAPI(tm) based XSVF by Antti Lukats - solutions from Amontec are not available. AnttiArticle: 120991
On 21 Jun., 15:39, cs_post...@hotmail.com wrote: > On Jun 21, 8:32 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > It looks to me like the one-per-card chips are probably buffer > > > memories of some sort. > > > sure, its very simple: > > > [ATA device IP Core] < BUFFER > [SD Host IP Core] > > + some small management state machine. > > You assume that the operation of the buffers is trivial. I suspect it > may not be. Even the ATA interface is non-trivial if you want to > support the faster transfer modes. There's probably a reason why it's > an FPGA and not simply a CPLD. > > I'm sure someone could make a more cost-optomized design, but at the > extremes of that, performance may suffer. Of course we could also be > looking at a product where someone plunked down the parts they thought > would be required to make a good solution, but shipped it before > getting their HDL code beyond minimal low-rate functionality. > > > it really is simple as that, but I would not call it "buffer memory of > > some sort" > > Oh, and absent information as to what type of "buffer memory" it is, > what exactly would you call it? i try to assume nothing. but, "buffer memory" would I think be proper for gadget where most of the complexity is "memory and/or buffer" a ATA-SD interface is something that includes some buffer memory, but the buffer memory is not the main function, as most of complecity is in the interface parts. AnttiArticle: 120992
At work I'm using a Nios CPU with Quartus 7.1. I've configured it with 512
bytes data and instruction cache, and it uses internal RAM. I have a struct
like this:
struct Something {
alt_u16 foo;
alt_u16 bar;
};
When modifying "foo" in a loop in main and "bar" of the same object in an
interrupt, it looks like sometimes it behaves like the interrupt overides
both variables, e.g. main increments "foo", but after the interrupt has
written "bar", the old value of "foo" is there, too. Maybe there is a bug
with memory cache updates? When I'm using "int" (or alt_u32), the problem
disappears.
Is there anything like this already known? If not, I'll try to extract a
simple test case.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Article: 120993
On Jun 21, 11:13 am, Frank Buss <f...@frank-buss.de> wrote:
> I have a struct like this:
>
> struct Something {
> alt_u16 foo;
> alt_u16 bar;
> };
>
> When modifying "foo" in a loop in main and "bar" of the same object in an
> interrupt, it looks like sometimes it behaves like the interrupt overides
> both variables, e.g. main increments "foo", but after the interrupt has
> written "bar", the old value of "foo" is there, too. Maybe there is a bug
> with memory cache updates? When I'm using "int" (or alt_u32), the problem
> disappears.
This really isn't FPGA related. This is actually a classic problem
(see comp.arch for lengthy and recurring discussions on this, notably
on Alpha). To know exactly what is going on you need to examine the
generated code, but I'm willing to bet that this is the classic RMW
problem. For a single-thread program, it is correct of read foo and
bar as a single 32-bit word, modify just the bar portion, and the
write back the full 32-bit word. However in the presence of multiple
threads (interrupts can be seen as a thread), this is not valid. If
NIOS lack 16-bit writes (doubt it), then you _have_ to use a int to
get atomic updates. Otherwise, you may be able to get the desired
behaviour by sprinkling volatile in the appropriate places, but IMO,
using int is safer and cleaner.
Regardless, study the disassembly of your interrupt service routine to
understand this problem (it's a race).
Tommy
Article: 120994Tommy Thorn wrote: > Regardless, study the disassembly of your interrupt service routine to > understand this problem (it's a race). This was my first idea, too and I have disassembled it and it uses "sth" and "ldh", which loads and saves 16 bit, so I think there might be a bug in the generated CPU core. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 120995
Frank Buss wrote: > This was my first idea, too and I have disassembled it and it uses "sth" > and "ldh", which loads and saves 16 bit, so I think there might be a bug in > the generated CPU core. One more hint why it might be a CPU core problem: I have configured Nios to use 32 bit block RAM, so it has to do some clever internal thing, if it writes to the same memory location from the main function and from interrupt. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 120996
Hello folks, I am using the V5 rocketio to implement a high speed serial IO. I have configured the GTP and it works , but the only problem is that the first 5 words ( comma and data) are corrupted at the receiver. I also ran the example design and it also reflects the same problem. Hence I guess there should be some problem in configuring the GTP tile. I had read the userguide over and over but still no luck . -- used TX buffer and RX buffer -- no clock correction used -- 8B/10B used -- no PRBS -- Line rate 2.5gbps request you help in finding my mistake. Thanks PCArticle: 120997
On Jun 21, 12:40 pm, Antti <Antti.Luk...@googlemail.com> wrote: > a ATA-SD interface is something that includes some buffer memory, but > the buffer memory is not the main function, as most of complecity is > in the interface parts. But buffer memory, and proper handling of it, may well make all the difference between a very good product, and a barely useable one. There's a bunch of these chips on the board. I suspect they are buffer memories, one per SD card. And I suspect that they are important, or at least would be if the product ended up working the way it was intended to when the PCBs were made, otherwise they wouldn't be there. There's also a controller, most likely in that spartan FPGA. Depending on what the buffers are used to accomplish, the controlling logic may be non-trivial.Article: 120998
It's time for a new scope, and I'm thinking of getting an Agilent MSO6000 series, in part because of the FPGA dynamic probe capability. Anyone here used that? How well does it work? Thanks PeteArticle: 120999
On 21 Jun., 22:00, cs_post...@hotmail.com wrote: > On Jun 21, 12:40 pm, Antti <Antti.Luk...@googlemail.com> wrote: > > > a ATA-SD interface is something that includes some buffer memory, but > > the buffer memory is not the main function, as most of complecity is > > in the interface parts. > > But buffer memory, and proper handling of it, may well make all the > difference between a very good product, and a barely useable one. > > There's a bunch of these chips on the board. I suspect they are > buffer memories, one per SD card. And I suspect that they are > important, or at least would be if the product ended up working the > way it was intended to when the PCBs were made, otherwise they > wouldn't be there. > > There's also a controller, most likely in that spartan FPGA. > Depending on what the buffers are used to accomplish, the controlling > logic may be non-trivial. there are 4 times IDE-SD ASIC's, from company called c-guys 1 per SD card. those chips include FULL IDE2SD interface, each of them has local onchip buffers for 2 sector FPGA does some management only, to combine the 4 IDE into one, the SD IP core is not inside the FPGA at all.. Antti
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