|
Message
From: "Damjan Lampret" <lampret@o...>
Date: Sun, 25 May 2003 17:08:43 -0700
Subject: Re: [openrisc] Request clarification
Jerry,
flash generic interface (FLASH_GENERIC, FLASH_GENERIC_REGISTERED) are used
only for simulation purposes (for regressions in order to have generate long
and short ack which is only possible with generic flash and not with actual
XSV flash interface which always take same amount of time and therefore is
not suitable for regression). Both defines are used in simulation script
(defined depending which iteration of regression is run at the moment of
regression simulation).
So bottom line if you are implementing for XSV board, ignore flash generic.
This is accomplished simply by not having any defines for flash generic.
Basically the code you need to synthesize is in the second part of the file
after the 'else (line 231).
This section should synthesize w/o problem, at least Synplify Pro doesn't
have any problems.
regards,
Damjan
----- Original Message -----
From: "Jerry English" <jenglish@w...>
To: <openrisc@o...>
Sent: Thursday, May 22, 2003 7:53 AM
Subject: [openrisc] Request clarification
> Greetings,
>
> I am attempting to put the ORP SOC into an Altera FPGA. I eliminated some
of the modules, VGA and audio come to mind.
>
> I was getting a "strange" error message from Quartus II verilog compiler
about not being able to process inverted tri state primitives.
> After tracking this down to the flash_top.v module I observed that the
`include bench_define.v had been commented out. Then searching for
> the definition of FLASH_GENERIC and FLASH_GENERIC_REGISTERED I found that
these were not defined anywhere. I am wondering why
> this is done in this manner.
>
> In order to get around the error message I commented out that section of
code within the undefined FLASH_GENERIC and FLASH_GENERIC_REGISTERED. The
code did compile. Clock speed is around 14 Mhz. The bottleneck appears to be
in the
> ALU shift operation.
>
> Regards
> Jerry
>
>
>
>
|
 |
Browse
