- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello all.
I'm trying to use the cy14v101qs model more precisely the cy14v101xs_ncvlog.vp.
In the config.v file the following defines are set:
`define CLOCK_20MHZ
`define PKG_16SOIC 1
In the log file I have the following messages from the memory:
INFO >> 5 ns >> TB_top_HQSPI_V400.i_cy14v101xs.i_up_mem
Power On Reset seen.
[150 ns ns] ==INFO== Power up: device fully accessible.
[150 ns ns] ==INFO== Protocol selected is extended
[150 ns ns] ==INFO== 3-byte address mode selected
[150 ns ns] ==INFO== Bottom 128M selected
The problem is that I can't get the vendor ID.
I send in SPI mode the command 0x9F (get ID) but I don't get any response from the memory.
I tried with 0x9E (fast get id) with the same result.
Did I do something wrong?
Thanks in advance for your help.
Best regards.
Sébastien.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Sébastien ,
Our physical memory has a weak internal pull-up of 100 kΩ for both HSB# and IO3 pins. This is mentioned in our datasheet. So, while simulating our model, you have to pull up these two pins.
I hope this answers your query.
Thanks,
Ritwick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Sébastien,
Did you test it using our test bench (tb_beh.v)? That file includes the test cases which has dpi_rdid instruction written in it.
Thanks,
Ritwick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good afternoon.
Thanks for your answer.
So far, I haven't done it because I didn't think I would have trouble driving it.
I will use it tomorrow and keep you posted.
Best regards.
Sébastien.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good afternoon.
Thanks to the waveforms, I understood where the problem came from.
In your test bench le following pins are are pulled up:
=> HSB_PIN
=> INT_PIN
=> IO3_PIN
=> WP_PIN
In mine, they were left unconnected since the memory is supposed to be in SPI mode after the reset and those I/O are unused.
The question I have is this: Are pull ups required on physical memory or is it just your model that does not support unconnected pins?
Thanks in advance for your ansewer.
Best regards.
Sébastien.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Sébastien,
INT pin should not come into the picture as you are using a non-RTC part. Could you please try by just pulling up the CE# and HSB# lines and let us know the result?
Thanks,
Ritwick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi.
Thanks for your answer.
The CE# pin is driven by a host in my test bench, so it is never left unconnected.
When I add a pull up on the HSB# pin, the memory model does not respond.
In order to have an expected behavior from the memory I have to add a pullup HSB# and IO3.
Here is a snapshot of my simulation (answer from a get_id command).
Sébastien.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Sébastien ,
Our physical memory has a weak internal pull-up of 100 kΩ for both HSB# and IO3 pins. This is mentioned in our datasheet. So, while simulating our model, you have to pull up these two pins.
I hope this answers your query.
Thanks,
Ritwick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good morning.
Thanks for your answer.
Yes, it does, but I thought the pull ups were integrated in the model to be closer to the physical memory.
Best regards.
Sébastien.